IMBS 
Publi- 
cations 

Computer  Science 
and  Technology 


NBS  Special  Publication  500-90 

Guide  to  Contracting 
for  Software  Conversion 
Services 


NATIONAL  BUREAU  OF  STANDARDS 


The  National  Bureau  of  Standards'  was  established  by  an  act  ot  Congress  on  March  3,  1901. 
The  Bureau's  overall  goal  is  to  strengthen  and  advance  the  Nation's  science  and  technology 
and  facilitate  their  effective  application  for  public  benefit.  To  this  end,  the  Bureau  conducts 
research  and  provides:  (1)  a  basis  for  the  Nation's  physical  measurement  system,  (2)  scientific 
and  technological  services  for  industry  and  government,  (3)  a  technical  basis  for  equity  in 
trade,  and  (4)  technical  services  to  promote  public  safety.  The  Bureau's  technical  work  is  per- 
formed by  the  National  Measurement  Laboratory,  the  National  Engineering  Laboratory,  and 
the  Institute  for  Computer  Sciences  and  Technology. 

THE  NATIONAL  MEASUREMENT  LABORATORY  provides  the  national  system  of 
physical  and  chemical  and  materials  measurement;  coordinates  the  system  with  measurement 
systems  of  other  nations  and  furnishes  essential  services  leading  to  accurate  and  uniform 
physical  and  chemical  measurement  throughout  the  Nation's  scientific  community,  industry, 
and  commerce;  conducts  materials  research  leading  to  improved  methods  of  measurement, 
standards,  and  data  on  the  properties  of  materials  needed  by  industry,  commerce,  educational 
institutions,  and  Government;  provides  advisory  and  research  services  to  other  Government 
agencies;  develops,  produces,  and  distributes  Standard  Reference  Materials;  and  provides 
calibration  services.  The  Laboratory  consists  of  the  following  centers: 

Absolute  Physical  Quantities-  —  Radiation  Research  —  Chemical  Physics  — 
Analytical  Chemistry  —  Materials  Science 

THE  NATIONAL  ENGINEERING  LABORATORY  provides  technology  and  technical  ser- 
vices to  the  public  and  private  sectors  to  address  national  needs  and  to  solve  national 
problems;  conducts  research  in  engineering  and  applied  science  in  support  of  these  efforts; 
builds  and  maintains  competence  in  the  necessary  disciplines  required  to  carry  out  this 
research  and  technical  service;  develops  engineering  data  and  measurement  capabilities; 
provides  engineering  measurement  traceability  services;  develops  test  methods  and  proposes 
engineering  standards  and  code  changes;  develops  and  proposes  new  engineering  practices; 
and  develops  and  improves  mechanisms  to  transfer  results  of  its  research  to  the  ultimate  user. 
The  Laboratory  consists  of  the  following  centers: 

Applied  Mathematics  —  Electronics  and  Electrical  Engineering-  —  Manufacturing 
Engineering  —  Building  Technology  —  Fire  Research  —  Chemical  Engineering- 

THE  INSTITUTE  FOR  COMPUTER  SCIENCES  AND  TECHNOLOGY  conducts 
research  and  provides  scientific  and  technical  services  to  aid  Federal  agencies  in  the  selection, 
acquisition,  application,  and  use  of  computer  technology  to  improve  effectiveness  and 
economy  in  Government  operations  in  accordance  with  Public  Law  89-306  (40  U.S.C.  759), 
relevant  Executive  Orders,  and  other  directives;  carries  out  this  mission  by  managing  the 
Federal  Information  Processing  Standards  Program,  developing  Federal  ADP  standards 
guidelines,  and  managing  Federal  participation  in  ADP  voluntary  standardization  activities; 
provides  scientific  and  technological  advisory  services  and  assistance  to  Federal  agencies;  and 
provides  the  technical  foundation  for  computer-related  policies  of  the  Federal  Government. 
The  Institute  consists  of  the  following  centers: 

Programming  Science  and  Technology  —  Computer  Systems  Engineering. 

'Headquarters  and  Laboratories  at  Gaithersburg,  MD,  unless  otherwise  noted; 
mailing  address  Washington,  DC  20234. 

'Some  divisions  within  the  center  are  located  at  Boulder,  CO  80303. 


Computer  Science 
and  Technology 


HATIONAL  BUBHAO 

or  standaedb 

LIBRARY 

JUL  1  9  1982 

H 

Oc/Go 


NBS  Special  Publication  500-90  ^^^i 

Guide  to  Contracting  i^^^ 

for  Software  Conversion 

Services 


Mark  W.  Skall 


Center  for  Programming  Science  and  Technology 
Institute  for  Computer  Sciences  and  Technology 
National  Bureau  of  Standards 
Washington,  DC  20234 


U.S.  DEPARTMENT  OF  COMMERCE 

Malcolm  Baldrige,  Secretary 

National  Bureau  of  Standards 

Ernest  Ambler,  Director 


Issued  May  1982 


Reports  on  Computer  Science  and  Technology 


The  National  Bureau  of  Standards  has  a  special  responsibility  within  the  Federal 
Government  for  computer  science  and  technology  activities.  The  programs  of  the 
NBS  Institute  for  Computer  Sciences  and  Technology  are  designed  to  provide  ADP 
standards,  guidelines,  and  technical  advisory  services  to  improve  the  effectiveness 
of  computer  utilization  in  the  Federal  sector,  and  to  perform  appropriate  research 
and  development  efforts  as  foundation  for  such  activities  and  programs.  This 
publication  series  will  report  these  NBS  efforts  to  the  Federal  computer  community  as 
well  as  to  interested  specialists  in  the  academic  and  private  sectors.  Those  wishing 
to  receive  notices  of  publications  in  this  series  should  complete  and  return  the  form 
at  the  end  of  this  publication. 


National  Bureau  of  Standards  Special  Publication  500-90 

Nat.  Bur.  Stand.  (U.S.),  Spec,  Publ.  500-90.  67  pages  (May  1982) 
CODEN.  XNBSAV 


Library  of  Congress  Catalog  Card  Number:  82-600531 


U.S.  GOVERNMENT  PRINTING  OFFICE 
WASHINGTON:  1982 


For  sale  by  the  Superintendent  of  Documents,  U.S.  Government  Printing  Office,  Washington,  D.C.  20402 

Price  $4.50 
(Add  25  percent  for  other  than  U.S.  mailing) 


TABLE  OF  CONTENTS 

Page 

1.  INTRODUCTION    1 

2.  CONVERSION  PHILOSOPHY    6 

3.  AGENCY  RESPONSIBILITIES  PRIOR  TO  RFP  CREATION    12 

M.    DESCRIPTION/SPECIFICATION  OF  SERVICES    34 

5.  DELIVERABLES  AND  ACCEPTANCE    42 

6.  INSTRUCTIONS  TO  OFFEROR    4? 

7.  EVALUATION  AND  AWARD  FACTORS    51 

8.  CONCLUSIONS    58 

Appendix  A:  Bibliography  and  References    61 


-iii- 


GUIDE  TO  CONTRACTING  FOR  SOFTWARE  CONVERSION  SERVICES 


MARK  W.  SKALL 


This  guide  is  the  first  in  a  series  of  publi- 
cations which  will  be  issued  by  the  National 
Bureau  of  Standards  with  respect  to  conversion  of 
Federal  agency  ADP  Systems.  The  need  for  these 
publications  was  determined  by  a  study  conducted 
in  1980,  consisting  of  interviews  with  commercial 
conversion  experts  and  Federal  Government  agency 
personnel  who  have  recently  experienced  conver- 
sions, as  well  as  a  search  of  the  current  litera- 
ture. The  results  of  that  study  are  documented  in 
NBS  Special  Publication  500-62,  entitled 
CONVERSION  OF  FEDERAL  ADP  SYSTEMS:  A  TUTORIAL. 
The  purpose  of  this  guide  is  to  educate  the 
Federal  manager  in  the  benefits  which  can  be 
gained  by  contracting  for  conversion  services  as 
well  as  to  specify  all  the  actions  the  agency  must 
take  to  ensure  a  successful  conversion  contract. 
The  guide  concludes  that  a  smooth  conversion  can 
be  accomplished  by  thoroughly  planning  the 
contractor's  activities  and  effectively  communi- 
cating these  plans  to  the  contractor. 

Key  words:  Acceptance  tests;  conversion  contract- 
ing; conversion  problems;  deliverables;  evaluation 
criteria;  Federal  agencies;  language  translators; 
portability;  program  inventory;  RFP;  statement  of 
work. 


1 .  INTRODUCTION 


The  conversion  of  computer  system  software  is  one  of 
the  most  costly,  difficult,  and  time-consuming  tasks  associ- 
ated with  the  use  and  maintenance  of  computer  software 
within  the  Federal  Government.  The  GAO,  in  a  report  enti- 
tled MILLIONS  IN  SAVINGS  POSSIBLE  IN  CONVERTING  PROGRAMS 
FROM  ONE  COMPUTER  IQ  ANOTHER,  [29]  estimates  that  over  $450 
million  is  spent  annually  on  Federal  computer  software 
conversion.  The  person  given  the  responsibility  of  managing 
the  conversion  effort    often    has    no    prior    experience  in 


managing  conversions,  and  the  programming  staff  assigned  to 
the  conversion  project  usually  has  only  a  minimal  background 
in  conversion.  It  is  unlikely  that  many  of  the  programming 
staff  participated  in  a  previous  conversion  at  the  same 
agency  since  the  average  time  between  computer  replacement 
in  Federal  agencies  was  found  to  be  seven  years,  which  is 
about  double  the  average  tenure  of  a  computer/programmer 
analyst  at  a  given  installation.  Additionally,  many  people 
on  the  conversion  staff  may  also  lack  an  intimate  knowledge 
of  the  software  requiring  the  conversion  due  to  staff  turn- 
over since  the  software  was  developed.  Thus,  the  general 
atmosphere  surrounding  the  initiation  of  a  large  scale 
conversion  can  be  filled  with  anxiety  and  uncertainty. 

Much  of  the  anxiety  and  uncertainty  can  be  alleviated 
if  the  conversion  is  contracted  out  to  an  experienced 
conversion  vendor.  Contracting  for  conversion  services  may 
be  the  only  alternative  since  hiring  freezes  and  personnel 
ceilings  prohibit  many  agencies  from  acquiring  additional 
personnel  beyond  those  needed  for  the  regularly  scheduled 
tasks.  Thus,  with  the  original  implementors  long  since 
gone,  and  documentation  frequently  inadequate  and  often 
out-of-date,  a  conversion  contractor  provides  the  conversion 
manager  with  a  more  optimistic  outlook  for  the  future. 

A  study  conducted  by  the  National  Bureau  of  Standards 
[3]  concluded  that  Federal  agency  personnel  who  are  involved 
in  writing  Requests  for  Proposals  (RFP's)  for  conversion 
services  are  very  often  confused  concerning  the  type  of  in- 
formation that  should  be  included  within  the  RFP,  the  types 
of  deliverables  which  need  to  be  specified,  and  the  ways  in 
which  to  ensure  that  the  conversion  has  been  completed 
correctly.  The  report  further  states  that  many  agencies 
which  have  contracted  for  conversion  services  in  the  past 
have  received  systems  whose  performance  is  inadequate  and 
may  not  meet  the  user's  needs.  This  situation  often  results 
from  the  agency's  reluctance  to  include  performance  require- 
ments as  part  of  the  acceptance  criteria  in  the  conversion 
RFP.  This  guide  addresses  the  problem  areas  cited  above  and 
thus  gives  Federal  agency  computer  managers  guidance  con- 
cerning a  large,  costly  and  extremely  time-consuming  project 
in  which  they  may  have  only  limited  experience. 

This  guide  contains  eight  chapters.  Chapter  1  provides 
background  material  on  conversion,  defines  terms,  and 
describes  the  need  for  this  guide.  Chapter  2  describes  the 
different  factors  which  an  agency  should  be  knowledgeable  in 
prior  to  undergoing  a  conversion.  Chapter  3  discusses  the 
role  of  the  agency  in  conversion.  Chapters  4  through  7 
describe  different  items  which  should  appear  in  an  RFP  for 
conversion  services,  while  chapter  8  is  a  summary  of  some  of 
the  important    points    brought    out    throughout    the  guide. 
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Note:  Bracketed  numbers,  i.e.  [N],  refer  to  references  in 
Appendix  A. 

Definition  of  Terms 

For  the  purposes  of  this  guide,  conversion  is  defined 
to  be  the  process  of  taking  application  software  in  source 
language  from  one  piece  of  equipment  and  modifying  it  to  ex- 
ecute correctly  on  another  piece  of  equipment,  while  main- 
taining the  functional  requirements  of  the  original 
software.  From  the  user's  viewpoint,  the  software  performs 
the  same  functions  in  the  old  and  new  environments.  The  ex- 
isting software  is  referred  to  as  the  source  program  or 
source  system  and  the  converted  software  is  referred  to  as 
the  target  program  or  target  system. 

Once  the  decision  to  convert  has  been  made,  there  are  a 
number  of  conversion  techniques  which  can  be  utilized.  This 
guide  will  consider  the  three  following  techniques,  which 
are  the  most  widely  used:  receding,  reprogramming ,  and 
redesign.    These  terms  are  defined  as  follows: 

*  Receding  -  Each  line  of  code  is  translated  to  an 
equivalent  line(s)  of  code  on  the  new  computer  sys- 
tem. This  translation  can  be  accomplished  manually 
through  visual  inspection  of  the  code,  automatically 
through  specialized  software,  or  by  a  combination  of 
the  two  techniques.  From  the  user's  and  designer's 
points  of  view,  the  system  remains  unchanged  (with 
the  exception  of  processing  time,  which  may  either 
have  increased  or  decreased.)  One  line  of  code  may 
get  translated  to  many  lines  of  code  or  many  lines 
of  code  may  get  translated  to  one  line  of  code.  The 
type  of  transformation  that  occurs  depends  upon  the 
source  and  target  languages.  Examples  are  COBOL  to 
COBOL,  assembly  language  to  COBOL,  and  FORTRAN  to 
FORTRAN.  If  the  source  and  target  languages  are 
similar,  much  of  the  translation  will  be  one-to-one. 

*  Reprogramming  -  Some  or  all  new  code  is  produced. 
All  the  code  is  not  translated  on  a  line-for-line 
basis,  but  the  same  functions  frcm  a  designer's  and 
user's  viewpoints  remain,  along  with  the  same  algo- 
rithms. Different  logic  is  used  to  program  the  same 
functions,  resulting  in  greater  efficiency. 

*  Redesign  -  A  new  system  specification  is  required. 
The  entire  design  of  the  system  may  change,  result- 
ing in  different  algorithms  to  accomplish  the  same 
functions.  Different  program  structure  and  dif- 
ferent logic  may  be  used.    New  techniques,    such  as 
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database  management,  may  be  incorporated,  and  the 
structure  of  program  files  may  change  drastically. 
The  new  system  specification  is  related  to  the  pre- 
vious system  because  the  same  functions,  from  the 
viewpoint  of  the  user,  are  produced.  Changes  in  the 
system  are  transparent  to  the  user. 

Why  Contract  Out  for  Conversion 

Lack  of  in-house  expertise,  personnel  ceilings,  and  ex- 
tremely tight  schedules  have  forced  Federal  agencies  to  ac- 
quire outside  conversion  assistance  to  meet  management's 
demands.  There  are,  however,  reasons  an  agency  may  want  to 
contract  out  for  conversion  services  because  of  the  qualifi- 
cations of  conversion  contractors.  Conversion  experience  is 
a  skill  which  must  be  acquired  by  participating  in  a  great 
number  of  conversions  in  various  programming  languages  and 
on  a  variety  of  different  source  and  target  computers.  Ccan- 
panies  specializing  in  conversion  employ  people  with  just 
this  mix  of  experience.  Experience  of  a  typical  conversion 
company  may  very  well  include  Federal  agencies  and  companies 
of  all  sizes,  ranging  from  contracts  involving  one  or  two 
programs  to  contracts  involving  hundreds,  or  even  thousands 
of  programs.  Many  large  conversion  companies  have  performed 
conversions  in  COBOL,  FORTRAN,  ALGOL,  Pl/1,  AUTOCODER  and 
other  programming  languages  and  have  utilized  the  following 
hardware:  Burroughs,  CDC,  Honeywell,  IBM,  NCR,  and  Univac, 
just  to  name  a  few.  Seme  conversion  companies  have  exper- 
tise with  data  base  management  and  communication  systems. 
Additionally,  conversion  companies  have  access  to  a  great 
number  of  software  tools,  designed  to  speed  up  and  assure 
greater  quality  assurance  in  the  conversion  process.  Scane 
tools  that  conversion  companies  utilize  are  language  trans- 
lators, file  comparators,  source  code  reformatters, 
analyzers  which  count  the  percentage  of  statements  executed 
by  test  data,  and  auditing  tools  which  check  adherence  to 
agency  standards. 

Historically,  programmers  have  viewed  conversions  as  an 
extremely  undesirable  activity.  They  are  "stuck"  with  a 
program  that  they  neither  designed  nor  coded,  and  now  they 
must  get  it  to  execute  correctly  on  a  machine  with  which 
they  may  not  be  familiar.  Furthermore,  conversion  is  viewed 
as  being  much  more  mechanical  and  not  nearly  as  intellectu- 
ally stimulating  as  new  coding  or  design.  The  above  prob- 
lems are  compounded  by  the  fact  that  the  natural  instinct  of 
most  individuals  is  to  resist  change,  and  cling  to  that  with 
which  they  are  most  familiar.  Thus,  retaining  good  morale 
among  programmers  assigned  to  conversion  projects  is, 
perhaps,  an  impossible  task.  The  U.S.  Navy  found  that  work- 
ing on  conversion  contributed  to  the  high  attrition  rate  of 
civilian    employees   more    than    any    other    activity  in  the 
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Navy's  data  centers.  This  factor  alone  may  justify  an 
agency's  decision  to  contract  out  for  conversion  services. 

The  PROVISIONAL  CHECKLIST  FOR  SOFTWARE  CONVERSION 
PROJECTS  [32],  prepared  by  the  U.S.  GENERAL  ACCOUNTING  OF- 
FICE states  that  "Contracting  (for  conversion  services)  is 
attractive  when:  a)  skilled  specialists  will  convert  for  a 
fixed  price,  b)  conversion  by  a  contractor  will  leave  in- 
house  staff  free  for  regular  tasks,  c)  experienced  conver- 
sion specialists  with  automated  aids  can  complete  the 
conversion  more  quickly  than  in-house  staff,  and  d)  little 
need  is  foreseen  to  redesign  the  programs  after  they  are 
converted." 
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2.    CONVERSION  PHILOSOPHY 


A  Federal  agency's  philosophy  concerning  the  way  to  ap- 
proach and  implement  the  conversion  process  will  have  a  pro- 
found effect  on  the  form  and  content  of  the  eventual  RFP  to 
acquire  conversion  services.  It  is  important  that  Federal 
agencies  understand  the  ramifications  of  their  decisions 
concerning  several  important  issues  which  materialize  during 
almost  all  conversion  projects.  Furthermore,  the  failure  of 
Federal  agencies  to  make  decisions  concerning  the  topics 
which  will  be  addressed  later  in  this  chapter  may  very  well 
lead  to  potential  conversion  contractors  making  these  deci- 
sions for  the  agency,  and  incorporating  them  into  their  pro- 
posal. Since  top  management  in  any  agency  should  not 
delegate  that  which  is  their  ultimate  responsibility,  it  is 
imperative  that  decisions  should  be  made  addressing  the 
areas  to  be  discussed  below. 

Improvements  During  Conversion? 

Many  existing  systems  of  programs  in  Federal  agencies 
were  designed  for,  and  are  operating  on,  computer  systems 
that  are  fifteen  years  old  and  older.  Many  of  these  pro- 
grams use  techniques  common  to  second  generation  computers, 
such  as  tape  oriented  files  rather  than  disc,  code  which  is 
not  modular  and  contains  few,  if  any,  ccxnments,  and  reliance 
on  operator  intervention.  Typically,  these  programs  are 
poorly  documented,  if  they  are  documented  at  all.  Certain- 
ly, an  agency  faced  with  converting  programs  in  this  state 
may  want  to  make  improvements  to  them  which  will,  at  least, 
make  the  programs  more  readable  and  maintainable. 

Some  of  the  improvements  which  can  be  made  to  programs 
during  conversion  are: 


The  use  of  more  recent  programming  methods  such  as 
structured  programming  or  modular  programming. 

The  addition  of  more  descriptive  comments.  Very  of- 
ten, much  time  is  invested,  during  conversions,  in 
scrutinizing  certain  sections  of  the  code  to  deter- 
mine the  logic.  This  is  valuable  information  once 
it  is  captured  and  should  not  reside  solely  in  the 
mind  of  the  person  who  analyzed  the  code.  Adding 
comments  to  the  program  will  prove  very  helpful  the 
next  time  someone  looks  at  this  section  of  the  code. 
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*  The  replacement  of  sequential  tape  files  with  disk. 

*  The  use  of  language  statements    contained    within  a 
FIPS  standard  language  with  no  vendor  extensions. 

*  The  use  of  internal    standards    for    naming  conven- 
tions. 

*  The  creation  of  a  test  plan. 

*  The  creation  of  test  data. 

*  The  creation  of  better  documentation. 

*  The  removal    of    operator    intervention    and  device 
dependency . 

A  conversion  effort  presents  an  opportunity  to  improve 
the  computer  syst«n.  Writing  the  RFP  to  include  improve- 
ments to  the  converted  programs,  such  as  the  ones  listed 
above,  should  be  encouraged  by  Federal  agencies,  since  they 
will  make  the  programs  easier  to  maintain  and  modify  after 
conversion  and  will  make  the  next  conversion,  if  it  is 
necessary,  a  much  easier  task.  However,  functional  changes 
that  will  affect  the  agency's  ability  to  map  the  output  of 
the  converted  programs  back  to  the  output  of  the  source  pro- 
grams should  be  avoided.  If  functional  changes  are  incor- 
porated, it  becomes  extremely  difficult  to  verify  whether  or 
not  a  system  of  programs  has  been  correctly  converted. 

If  it  is  deemed  absolutely  necessary  to  make  functional 
changes  to  a  system  of  presently  running  programs  which  are 
being  converted  under  contract,  then  these  changes  should  be 
made  by  the  Federal  agency's  programming  staff  and  should  be 
thoroughly  documented  so  that  these  changes  can  be  incor- 
porated into  the  converted  programs  after  canpletion  of  the 
conversion  effort. 

Acceptance  Testing 

When  a  conversion  is  being  done  under  contract,  how 
does  the  agency  know  that  the  contractor  has  successfully 
completed  the  effort?  Some  absolute  criteria  must  be  used 
to  make  this  determination.  These  criteria  are  referred  to 
as  acceptance  criteria.  More  detail  concerning  acceptance 
criteria  will  be  discussed  later  in  the  report  when  details 
of  the  RFP  are  presented.  A  brief  summary  of  the  major  as- 
pects of  acceptance  criteria  is  presented  below: 
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*  The  converted  programs  must  meet  design  and  specifi- 
cation criteria. 

*  The  converted  programs  must  meet  processing  time 
criteria. 

*  The  converted  programs  must  meet  accuracy  criteria. 

*  The  output  of  the  converted  programs  operating  with 
converted  files  must  equal  the  output  of  the  source 
programs  and  files. 

*  The  output  of  the  converted  systems  operating  with 
converted  files  shall  equal  the  output  of  the  source 
systems  and  files. 

*  Documentation  must  be  supplied  indicating  all  pro- 
gramming changes  which  were  made  to  the  structure  or 
the  logic  of  the  programs  in  the  process  of  convert- 
ing from  the  source  to  the  target  machine. 

*  Execution  monitoring  must  demonstrate  that  a 
predetermined  percentage  of  the  code  is  actually  ex- 
ecuted during  testing. 

Type  of  Contract 

Much  of  the  current  literature  about  conversion  advo- 
cates fixed  priced  contracts  for  conversion  products.  The 
argument  is  that  conversion  is  the  only  software  project 
which  has  a  concise  specification  for  the  products  desired. 
This  specification  is  the  source  programs  themselves,  which 
define  the  functions  which  need  to  be  converted  to  the  tar- 
get environment.  If  the  acceptance  tests  in  the  contract 
are  precise  and  canprehensive,  coupled  with  liquidated  dam- 
ages for  failure  to  satisfy  them,  a  fixed  price  contract 
does  indeed  look  very  desirable. 

The  problem  with  fixed  price  contracts  is  that  the  job 
must    be    well  enough  defined  for  prospective  contractors  to 
be  able  to  make  accurate  cost  estimates  for  the  conversion. 
Many    conversion  companies  maintain  comprehensive  data  bases 
for  conversion  cost  estimation.    However,  these    data  bases 
are    usually    based    on    using    receding    to    accomplish  the 
conversion.       Receding     only       guarantees  functionally 
equivalent    source  code,  not  a  program  which  runs  efficient- 
ly.   If  performance  and  efficiency  constraints  are  included 
as  part  of  the  acceptance  criteria  (as  they  should  be),  then 
the  scope  of  the  effort  is  not  known  with  as  much  certainty 
since  a  great  deal  of  tuning  of  the  code  may  be  necessary  in 
order    to   meet    certain    performance    and    efficiency  con- 
straints,   such    as  execution  speed  and  memory  requirements. 
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Contractors  may  be  compelled  to  switch  to  reprogramming  or 
redesign  to  accomplish  much  of  the  conversion.  Cost  esti- 
mates for  these  methods  are  much  more  difficult  to  make, 
since  these  methods  can  not  be  automated  to  the  same  degree 
as  receding. 

One  useful  set  of  criteria  that  can  be  used  in  deciding 
among  conversion  techniques  was  specified  in  an  NBS  Special 
Publication  entitled  CONVERSION  OF  FEDERAL  ADP  SYSTEMS;  A 
TUTORIAL  [3],  and  is  listed  below: 


*  Recoding  -  Source  and  target  languages  should  be 
similar.  The  source  and  target  computers  should 
have  comparable  hardware/  software  capabilities.  If 
recoding  is  used  when  hardware/ software  capabilities 
are  not  comparable,  then  the  capabilities  of  the  new 
computer  may  not  be  utilized,  often  resulting  in 
inefficient  programs. 

*  Reprogramming  -  Source  and  target  languages  are  dis- 
similar (e.g.,  converting  from  assembler  to  COBOL). 
Line-for-line  translation  (or  recoding),  when  the 
source  and  target  languages  are  dissimilar,  may  well 
result  in  converted  code  which  is  much  larger  than 
the  source  code.  For  example,  in  a  conversion  of 
assembly  language  to  COBOL,  assume  that  the  first 
assembly  language  statement  loads  register  1  with 
variable  A;  the  second  statement  loads  register  2 
with  variable  B;  the  third  statanent  adds  the  con- 
tents of  register  1  to  register  2;  and  the  fourth 
statement  puts  the  new  contents  of  register  2  in 
variable  C.  Some  translators,  performing  line-for- 
line  conversion,  may  generate  four  COBOL  statements 
corresponding  to  these  assembly  language  statements. 
In  turn,  when  these  COBOL  statements  are  compiled 
and  assembled,  they  will  produce  16  assembly 
language  statements,  producing  a  four- fold  code  ex- 
pansion. A  good  programmer,  using  reprogramming 
rather  than  recoding,  would  produce  COBOL  code  say- 
ing "ADD  A  TO  B  GIVING  C",  which  would  execute  much 
more  efficiently. 

*  Redesign  -  The  source  program  is  many  generations 
old.  The  design  is  out-of-date,  and  the  program  is 
poorly  structured  and  documented.  The  agency 
desires  a  more  modular,  maintainable,  and  readable 
program. 
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A  manager  can  implicitly  specify  the  appropriate 
conversion  technique  by  embedding  performance  requirements 
into  the  conversion  RFP.  In  this  way,  the  contractor  is  le- 
gally obliged  to  address  constraints  specified  in  the  RFP 
(such  as  response  time,  memory  requirements,  size  of  tiie 
target  program,  etc.).  The  choice  of  receding  as  a  conver- 
sion technique  will  often  fail  to  result  in  the  target  pro- 
gram satisfactorily  meeting  these  performance  constraints. 
In  fact,  translators,  which  use  the  receding  philosophy, 
have  been  known  to  produce  an  object  expansion  rate  of  10  to 
15  times.  Thus,  if  the  new  computer  is  six  times  faster 
than  the  old  one,  the  converted  programs  will  execute  at 
about  one-half  the  speed  as  before  conversion.  When  perfor- 
mance requironents  are  embedded  in  the  RFP,  the  contractor 
is  placed  in  the  ideal  situation,  from  the  agency's  stand- 
point. The  contractor  will  still  attempt  to  utilize  the 
most  economical  and  timeliest  technique  possible,  but  this 
technique  must  also  meet  the  performance  requirements. 
Thus,  the  product  that  the  agency  will  obtain  is  the  one 
that  is  the  least  costly  and  most  efficient,  but  also  satis- 
factorily meets  minimum  performance  requirements. 

Many  agencies  fail  to  include  any  performance  con- 
straints in  the  RFP,  asking  instead  for  functionally 
equivalent  source  code.  This  can  lead  to  degradation  in 
performance,  as  illustrated  in  the  the  assembler  to  COBOL 
translation  documented  above,  and  may  result  in  a  converted 
system  which  does  not  meet  the  user's  needs. 

In  suiraiary,  for  a  conversion  which  only  needs  to  be 
receded,  the  scope  of  work  can  be  precisely  defined  and  ac- 
ceptable cost  estimates  can  be  made.  Generally,  conversions 
which  have  stringent  performance  requirements  can  not  be  ac- 
complished solely  by  receding.  If  stringent  performance  re- 
quirements are  specified,  then  reprogramming  or  redesign 
will  probably  be  the  preferred  method  of  conversion,  and  the 
contract  may  very  well  net  be  fixed  price.  Remember  that 
the  decision  concerning  the  type  of  contract  is  determined 
by  the  specifications  in  the  RFP.  The  final  selection  of 
the  type  of  contract,  however,  should  be  made  only  after 
consultation  with  the  Contracting  Officer. 

Maintaining  Control  Over  the  Contractor 

GAO,  in  a  report  entitled  CONTRACTING  FOR  COMPUTER 
SOFTWARE  DEVELOPMENT— SERIOUS  PROBLEMS  REQUIRE  MANAGEMENT 
ATTENTION  TO  AVOID  WASTING  ADDITIONAL  MILLIONS  [28],  points 
out  that  agencies  quickly  overcommit  themselves  and  fail  to 
control  contractors  through  specific  clauses  in  the  RFP. 
Seme  methods  which  can  be  used  to  control  contractors  are: 
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tight  contract  monitoring, 
strict  phasing, 

requiring  written  progress  reports, 

specifying  the  standards  to  which  the  contractor 
must  adhere, 

identifying  critical  milestones, 

identifying  a  single  focal  point  for  communication, 

conducting  audits  to  verify  if  deliverables  are 
correct. 


Agencies  often  commit  thanselves  to  the  entire  contract 
without  receiving  feedback  as  to  whether  or  not  the  prelim- 
inary phases  of  the  contract  are  being  performed  satisfac- 
torily. Smaller  pieces  of  the  total  system  should  be  iden- 
tified as  critical  milestones  in  the  preliminary  phases  of 
the  contract  and  a  determination  can  then  be  made  as  to 
whether  or  not  these  programs  have  been  successfully  con- 
verted, before  allowing  the  contractor  to  continue  with  the 
contract.  The  determination  as  to  whether  or  not  the  pro- 
grams have  been  successfully  converted  should  include 
predetermined  criteria  for  the  unit  test  plan  and  test  re- 
port, the  percent  of  statements  that  have  been  executed  dur- 
ing testing  and  the  performance  of  the  converted  programs. 
Written  progress  reports  should  be  required  by  the  contract 
in  order  to  keep  the  agency  apprised  of  progress  and  the  at- 
tainment of  critical  milestones,  as  well  as  potential  prob- 
lems. 

To  improve  communications  and  to  eliminate  conflicting 
information  emanating  from  the  contractor,  agencies  should 
establish  a  single  person  as  a  focal  point  for  communica- 
tions with  the  contractor. 


* 
« 


-11- 


3.    AGENCY  RESPONSIBILITIES  PRIOR  TO  RFP  CREATION 


Before  a  contractor  can  begin  a  contract  to  convert  a 
computer  system,  much  work  must  be  done  by  the  agency's 
staff  to  produce  inputs  for  the  contactor.  In  fact,  agency 
people  who  are  knowledgeable  about  the  system  which  is  being 
converted  must  be  intricately  involved  throughout  the 
conversion  effort  if  the  conversion  is  to  be  successful. 

The  most  obvious  and  also  the  most  important  task  to  be 
done  by  the  agency's  staff  is  the  identification  of  exactly 
what  is  to  be  converted.  This  task  provides  agency  person- 
nel the  opportunity  to  scrutinize  the  existing  system  of 
programs  and  to  make  assessments  as  to  which  of  these  pro- 
grams are  still  functional  and  thus,  should  be  converted. 

Identifying  what  is  to  be  converted  is  accomplished  by 
taking  a  complete  inventory  of  all  programs,  files,  data 
bases  and  documentation  which  pertain  to  the  source  systan. 
Many  conversion  authorities  advocate  using  some  form  of 
conversion  inventory  worksheet  to  identify  all  the  program, 
file  and  data  base  components.  Some  worksheets  recommended 
by  GSA's  Federal  Conversion  Support  Center  (FCSC)  [8]  and 
used  by  the  Department  of  the  Anny  [15]  are  shown  in  figures 
1  through  6.  Figures  1  and  2  are  the  FCSC  worksheets  and 
figures  3  through  6  are  from  the  Department  of  the  Army. 
Conversion  type  in  figures  4  and  5  refers  to  the  degree  of 
difficulty  involved  in  converting  the  file.  Type  A  is  the 
easiest  type  of  file  to  convert,  type  B  the  second  easiest, 
and  type  C  the  most  difficult  type  of  file  to  convert.  The 
information  required  in  these  worksheets  is  the  absolute 
minimum  needed  by  the  contractor  to  successfully  complete 
the  conversion.  We  recommend  that  an  agency,  which  is  about 
to  undergo  a  conversion,  examine  these  sample  worksheets  and 
determine  whether  or  not  they  are  sufficient  for  its  needs. 
If  these  worksheets  are  not  sufficient,  the  agency  should 
devise  some  to  meet  its  needs.  Following  is  a  list  of  items 
to  choose  from  when  developing  a  conversion  inventory 
worksheet.  This  list  is  very  comprehensive  and  may  include 
items  not  relevant  to  a  particular  system  of  programs. 
Thus,  in  devising  a  worksheet,  an  agency  should  include  only 
the  itans  on  the  list  vrtiich  are  pertinent. 
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System:    Weapons  Component  Procurement  System 


No. 

Documentation  Component 

Complete 

Incomplete 

Not 
Applicable 

. — .  . — 

1 

Application  Description 

A 

i 

z 

bystem  r±ow  Ltiart 

Y 
A 

3 

Program  Narrative 

A 

i    '  \ 

/. 

Program  Flow  Chart /Decision  Table 

Y 

A 

Algorithm  Description 

X 

6 

File  Layouts 

X 

7 

Reports 

X 

8 

Test  Data  Printouts 

- 

9 

Program  Listings 

X 

10 

User  Instructions 

X 

11 

Data  Preparation  Instructions 

12 

Control  Clerk  Instructions 

X 

13 

Run  Sheets 

X 

Comments:     System  maintenance  performed  without  documentation  update. 
Transaction  and  master  file  formats  are  out  of  date. 


FIGURE  6.     DOCUMENTATION  REVIEW  FORM 


System  Information 


*  System  identifier 

*  Point  of  contact 

*  Date  the  inventory  is  prepared 

*  Description  of  system 

*  Source  computer 

*  Target  computer 

*  Operating  system 

*  Name  and  number  of  all  application  programs  in  sys- 
tem 

*  Total  lines  of  source  code  of  each  application  pro- 
gram in  system 

*  Name,  number  and  total  source  code  lines  of  all  pro- 
grams in  the  system  grouped  according  to  the 
language  they  are  written  in 

*  Name  and  number  of  all  files  in  system 

*  Name  and  number  of  all  common  subroutines  in  system 

*  Name  and  number  of  all  data  bases  in  system 

*  Name  and  number  of  all  stand-alone  utilities  in  sys- 
tem 

*  Name  and  number  of  all  programs  by  size:  a) Under 
1000  lines,  b)1000  -  10,000  lines,  or  c)greater  than 
10,000  lines 

*  Run  frequency  of  the  system 

*  Name  and  number  of  all  user  coded  macros 

*  Interfaces  within  the  system 

*  Interfaces  to  other  systems 

*  Description  of  present  DBMS  functions  and  capabili- 
ties 


*  Identification  of  general  purpose  interactive  time- 
sharing requirements 

*  Identification  of  security  and  privacy  requirements 

*  Identification  of  all  proprietary    packages    in  the 
system 

*  Description  of  the  documentation  which  exists 

B.  Program  Information  -  For  each  program  identified  in  the 
Syst«n  Information  section,  the  following  should  be  identi- 
fied: 


*  Program  identifier, 

*  Point  of  contact, 

*  Date  the  inventory  is  prepared, 

*  Description  of  program,  ^ 

*  Source  language  and  version  (e.g.,  FORTRAN  66), 

*  Source  computer, 

*  Target  computer, 

*  Target  language  and  version  (e.g.,  FORTRAN  77) i 

*  Operating  system  (source  and  target), 

*  Number  of  lines  of  source  code  -  a) number  of  lines 
of  standard  code,  b) number  of  lines  of  non-standard 
code, 

*  Documentation  of  existing  and  potential  problems, 

*  Name  and  number  of  all  called  subprograms, 

*  Name  and  number  of  all  input  files, 

*  Name  and  number  of  all  output  files, 

*  Name  and  number  of  all  stand-alone  utilities  used, 

*  Number  of  patched  statements  in  object  program. 
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«  DBMS  interfaces, 

*  Telecommunications  interfaces, 

*  Are  checkpoint  restart  capabilities  present? 

*  Does  comprehensive  test  data  exist  for  this  package? 

*  Size  of  test  data  (average  number  of  bytes/file), 

*  Percentage  of  statements  executed  by  this  test  data, 

*  Actual  JCL  used  by  the  program, 

*  Description  of  the  overlays  used  by  the  program, 

*  Description  of  the  documentation  which  exists. 

C.  File  Information  ~  For  each  file  identified,  the  follow- 
ing information  should  be  supplied: 

*  File  identifier, 

*  Point  of  contact, 

*  Date  the  inventory  is  prepared, 

*  Description  of  the  file, 

*  Source  program(s)  that  reads  the  file, 

*  Source  program(s)  that  writes  the  file, 

*  Media  (mag.  tape,  disc,  etc.), 

*  Access  method, 

*  Record  format, 

*  Number  of  records, 

*  Average  record  size. 

D.  Documentation  -  The  following  documentation  should  be 
identified: 

*  User  manuals. 
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*  Local  operating  manuals, 

*  Local  programming  standards  and  procedures  manual, 

*  Hardware  manuals, 

*  System  software  manuals, 

*  Computer  manuals, 

*  Original  test  plan, 

*  Program  listings, 

*  Program  flow  charts, 

*  Functional  specifications, 
:=.     *  Data  requirements, 

*  Design  specifications, 

*  Identification  of  any  deviations  frcan  original  func- 
tional or  design  specifications, 

*  Data  description, 

*  Sample  input  and  output  listings, 

*  Sample  input  data,  if  it  exists,  in  machine  readable 
form, 

*  Operator  manuals,  run  books, 

*  Maintenance  manual. 

After  a  complete  inventory  of  all  systems,  programs, 
files,  data  bases,  and  documentation  has  been  completed,  it 
is  very  useful  to  develop  cross  reference  lists  between  the 
programming  languages  used  and  the  types  of  application 
software,  as  well  as  a  program  distribution,  by  language, 
and    a  file  distribution  within  each  department.    The  sample 

charts  in  figures  7  through  10  [15]  may  be  helpful  in  this 
effort.  In  Figure  9,  file  types  A,  E  and  C  describe  the 
conversion  difficulty  of  the  file.  Type  A  is  the  easiest 
and  cheapest  type  of  file  to  convert.  An  example  of  a  type 
A  file  is  a  character  data  file.  Type  B  is  more  difficult 
and  expensive  to  convert  than  type  A.  Type  C  is  the  most 
difficult  and  expensive  type  of  file  to  convert.  An  example 
of  a  type  C  file  is  a  packed  or  compressed  file  with  vari- 
able record  format. 
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File  Type 

Dept . 

No.  of  Unique 

Files/No.  Records 

A 

.      '  r 

B     (  C 

SAB 

18 

23,000 

X 

SSB 

1 

685 

X 

SSB 

3 

2,161 

X 

HSS 

36 

76,432 

X 

HPS* 

10 

186 ,490 

X 

HPS 

5 

4,000 

X 

f 

HMP* 

2 

6,000 

X 

HMP* 

4 

28,000 

CAU 

89 

113,418 

X 

i 

1 

CAB* 

15 

146,382 

X 

i 

TOTALS 

183 

586,568 

*Data  base  files 
i  


FIGURE  9.     SAMPLE  FILE  SmiMARY:  CONVERSION 
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CONVERSION  MAN- 

-MONTH 

ESTIMATES 

1 

Language* 

Number 

Number 

Programs 

Files 

Totals 

Dept. 

he- 

DB      F  A 

- 

Programs 

T7-?  1  £1  e 

r  ixes 

Low 

Low 

Hi 

Low 

Hi 

DAB 

X 

82 

18 

SSB 

i — 

X 

35 

4 

1 

HSS 

1 — 

X 

80 

36 

HPS 

X 

V 

A 

X 

13 
10 
4 

5 
10 
0 

i  ' 

HMP 

X 

X 

27 
6 

0 
6 

— 1 

( 

CAU 

! 

X 

X 

X 



64 

23 

12 

— ^— ^— ^— 
78 

11 

0 

CAD 

X 

X 

00  00 

15 
0 

i 

 f 

! 
1 

TOTALS 

372 

183 

*C  =  COBOL 

DB  =  Data 

Base          F  = 

FORTRAN 

A  = 

=  Assembly  language 

FIGURE  10.     PROGRAM/FILE  DISTRIBUTION  BY  DEPARTMENT 
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Assessing  the  Future 


After  a  complete  inventory  has  been  taken,  decisions 
can  then  be  made  as  to  the  future  of  all  the  programs  and 
files  identified.  This  phase  of  the  conversion  presents 
agency  personnel  with  a  golden  opportunity  to  "clean  up"  an 
existing  system.  Perhaps,  some  of  the  programs  or  files 
identified  in  the  various  checklists  can  be  "thrown  away" 
(i.e.  not  converted  to  the  target  system)  because  the  func- 
tions they  perform  are  not  needed  anymore.  Even  if  program 
functions  are  still  needed,  usable  programs  may  already  ex- 
ist for  the  new  system  which,  with  little  or  no  additional 
effort,  can  reproduce  the  functions  of  the  old  program. 

Moreover,  the  old  software  may  be  so  poorly  designed  or 
inefficient  that  it  should  be  discarded  and  new  applications 
written  for  the  system.  It  may,  in  fact,  be  easier  to  write 
some  new  programs  from  scratch  than  to  convert  them  to  the 
target  system.  An  assessment  should  also  be  made  of  the  fu- 
ture expected  life  of  each  program.  It  may  be  that  certain 
programs  will  only  be  needed  for  a  short  time  following  the 
conversion.  In  this  case,  a  quicker,  cheaper  alternative  to 
conversion  (such  as  emulation  or  simulation)  should  be  in- 
vestigated for  these  programs.  If  the  decision  to  convert 
the  programs  is  made,  the  various  conversion  techniques 
identified  in  chapter  1  should  be  investigated. 

The  users  should  be  brought  into  the  process  at  this 
stage.  They  may  reconmend  that  certain  functions  be  deleted 
or  modified.  If  functions  are  deleted,  existing  application 
programs  may  not  have  to  be  converted.  Comments  should  also 
be  solicited  from  users  concerning  the  existing  output. 
They    may    recommend  that  the  output  should  be  modified.  Be 

careful,  however,  when  attempting  to  modify  the  output, 
since  it  is  imperative  to  be  able  to  map  the  output  of  the 
source  system  to  the  output  of  the  target  system.  It  is 
therefore  recommended  that  changes  made  to  the  programs 
which  affect  the  output  be  made  prior  to  the  beginning  of 
the  translation  phase  or  subsequent  to  the  completion  of 
system  testing. 

The  users  should  also  be  able  to  help  determine  the  re- 
lative priority  of  the  various  application  programs,  thus 
helping  determine  which  programs  should  be  converted  in  the 
first  batch  by  the  contractor.  The  inclusion  of  organiza- 
tional priorities  into  the  RFP  will  help  ensure  that  the 
conversion  schedule  developed  will  be  responsive  to  the 
agency's  needs,  while  interfering  as  little  as  possible  with 
the  existing  operation. 
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Note  Existinp:  Conversion  Difficulties 


All  programs  which  have  been  identified  on  the  program 
worksheet  as  having  potential  problems  should  now  be  re- 
viewed in  depth  to  determine  the  nature  of  these  problems. 
A  program  is  defined  as  having  no  conversion  difficulties  if 
it  can  be  converted  to  another  computer  by  reccanpiling  and 
correcting  only  syntax  errors.  If  the  program  has  conver- 
sion difficulties,  these  difficuties  should  be  documented  in 
a  separate  list.  The  noted  conversion  difficulties  general- 
ly fall  into  two  groups: 

1 .  Extensive  logic  changes  needed  which  affect  the  pro- 
gram throughout  (e.g.,  a  FORTRAN  array  which  is 
larger  than  the  new  system  can  accomodate  must  be 
redesigned,  and  the  logic  to  access  the  array  must 
be  rewritten) 

2.  Code  replacement  needed,  affecting  the  program  in  a 
specific,  limited  area  (e.g.,  replacing 
ENCODE/DECODE  in  FORTRAN  with  a  more  widely  accepted 
input/ output  method) 


This  detailed  list  and  analysis  of  potential  conversion 
difficulties  will  make  the  contractors'  job  less  costly 
(since  they  don't  have  to  determine  these  problem  areas  for 
themselves)    and  helps  assure  that  these  major  problem  areas 

are  addressed  in  the  conversion.  The  charts  which  are 
described  in  Figures  11  and  12  [15]  may  be  of  help  in  deter- 
mining   how    prevalent    potential    conversion    problems  are 

within  the  existing  code. 
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Data  Preparation 

Data  preparation  is  the  process  of  gathering  all  the 
materials  that  will  be  used  in  the  conversion.  The  agency 
staff  should  do  the  vast  majority,  if  not  all,  of  the  data 
preparation  since  they  are  the  most  qualified  to  identify 
the  types  and  sequence  of  information  to  gather,  and  the 
ways  in  which  to  prepare  the  conversion  materials.  During 
data  preparation,  the  agency  staff  must  ensure  that  all  the 
inputs  to  the  conversion  process,  (which  should  have  been 
derived  from  the  conversion  inventory  worksheet,  and  modi- 
fied based  on  each  program's  usefulness  on  the  new  system) 
are  available  to  be  used  by  the  contractor.  These  inputs 
should  include  program  source  listings,  input  files,  record 
layouts,  documentation,  etc. 

Test  files  must  be  generated  to  ensure  that  the  con- 
tractor adequately  tests  and  validates  the  converted  system. 
Thus,  test  data  that  can  exercise  at  least  70  percent  of  the 
program  code  should  be  generated  on  the  source  system. 
Although  the  study  of  testing  is  currently  in  the  research 
stage,  the  70  percent  figure  is  regarded  by  conversion  spe- 
cialists to  be  a  reasonable  rule  of  thumb.  However,  the  70 
percent  figure  should  be  adjusted  depending  upon  the  impor- 
tance of  the  code  tested.  If  the  code  is  crucial  to  the 
operation  of  a  system,  test  data  that  exercises  80  percent 
or  even  90  percent  of  the  program  code  may  be  appropriate. 
It  is  desirable  to  keep  the  input  data  test  files  as  small 
as  possible,  while  still  providing  adequate  testing.  A  test 
file  should  be  small  enough  to  yield  acceptable  run  times 
for  the  converted  program,  and  still  be  representative  of 
data  that  can  test  70  percent  of  the  code.  Test  data  files 
(as  well  as  listings)  are  needed  for  each  program  identified 
on  the  conversion  inventory  worksheet. 

After  test  files  that  test  an  acceptable  amount  of  code 
are  developed,  each  source  program  should  be  recompiled  and 
run  with  the  test  files,  producing  sample  output.  Later  on, 
during    the    testing    phase    of  the  conversion  contract,  the 

contractor  will  use  this  sample  output  as  a  comparison  for 
the  actual  output  of  the  converted  programs  to  determine  if 
the  programs  have  been  converted  correctly,  from  a  function- 
al standpoint. 

Determine  Manpower  and  Computer  Resource  Estimates 

Before  an  RFP  for  conversion  services  can  be  completed, 
estimates  must  be  made  by  the  agency  as  to  the  resources  re- 
quired for  the  contract.  Specifically,  the  agency  must 
develop  a  conversion  workload  estimate  that  itemizes  the 
manpower  estimate,  as  well  as  the  computer  costs,  to  com- 
plete   the    conversion    effort.      Estimating  the  staff  time, 
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computer  costs,  and  time  necessary  to  complete  the  conver- 
sion is  not  an  easy  task.  There  is  no  universal  formula  for 
estimating  conversion  costs,  and  it  is  beyond  the  scope  of 
this  guide  to  develop  a  comprehensive  discussion  of  this  to- 
pic. A  recent  publication  by  GSA,  entitled  REVIEW  AND 
ANALYSIS  OF  CONVERSION  COST-ESTIMATING  TECHNIQUES  [91,  ad- 
dresses this  topic. 

A  useful  approach  which  may  aid  agencies  in  determining 
conversion  resource  requirements  is  the  development  of  a 
prototype  conversion.  In  this  approach,  a  representative 
sample  of  the  programs  to  be  converted  is  chosen,  along  with 
qualified  people  to  perform  the  conversion.  It  is  doubtful 
that  in-house  people  would  be  available  to  perform  a  proto- 
type conversion  since  a  major  reason  for  contracting  out  for 

conversion  services  in  the  first  place  is  a  lack  of  quali- 
fied people  available  in-house.  It  may,  therefore,  be  ap- 
propriate to  include  the  prototype  conversion  as  the  ini- 
tial task  for  the  ensuing  conversion  contract,  or  as  a 
separate  preliminary  contract.  A  separate  preliminary  con- 
tract is  preferable  since  the  cost    estimates    derived  from 

the  prototype  can  be  used  in  negotiations  with  the  offerors 
for  the  follow-on  conversion  contract.  Reference  [21]  may 
be  useful  in  helping  to  determine  these  estimates. 

Two  factors  will  necessitate  adjustments  to  the  parame- 
ters derived  from  the  prototype.  One  is  the  initial  learn- 
ing phase  which  will  undoubtedly  cause  the  time  estimate  to 
be  high.  The  other  factor  is  the  interrelationship  problems 
which  must  be  solved  when  systems  are  highly  interconnected. 

The  prototype  may  not  be  representative  of  system  interrela- 
tionships, and  consequently,  the  time  estimates  derived  from 
the  prototype  would  be  low.  Probably  the  most  critical  fac- 
tors affecting  the  parameters  are  the  abilities  and  experi- 
ence of  the  people  who  will  perform  the  conversion.  Conver- 
sion is  likely  to  be  more  successful,  and  accomplished  in 
fewer  staff-hours,  when  performed  by  people  experienced  in 
conversion. 

Summary  of  Functions  to  be  Accomplished  Prior  to  the  RFP 

In  summary,  it  is  imperative  that  a  Federal  agency  un- 
dergoing a  conversion  perform  the  following  functions,  prior 
to  releasing  the  RFP: 

*  Identification  of  what  is  to  be  converted  -  This  is 
accomplished  by  taking  a  complete  inventory  of  all 
programs,  files,  data  bases,  and  documentation. 
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*  An  assessment  of  the  future  of  all  programs  -  Deci- 
sions may  be  made  to  discard  programs  because  they 
were  poorly  designed  or  inefficient  and  to  develop 
new  applications  for  the  target  system.  Certain 
programs  may  only  be  needed  for  a  short  time  on  the 
target  system  and  a  cheaper  alternative  to  conver- 
sion may  be  chosen  for  these  programs.  Users  may 
recommend  that  certain  functions  be  deleted  or  modi- 
fied. Finally,  users  should  also  help  to  determine 
the  relative  priority  of  the  various  programs. 

*  A  review  of  existing  conversion  difficulties  -  All 
programs  which  have  been  identified  in  the  program 
inventory  as  having  potential  problems  should  be  re- 
viewed   in    depth    to    determine  the  nature  of  these 

problems. 

*  Data  preparation  -  The  agency  staff  must  ensure  that 
all  inputs  to  the  conversion  process  are  available 
to  be  used  by  the  contractor.  These  inputs  include 
program  source  listings,  input  files,  record  lay- 
outs, documentation,  etc. 

*  The  generation  of  test  files  -  The  agency  should 
generate  test  files  that  can  exercise  at  least  70 
percent  of  the  program  code.  Each  source  program 
should  be  executed  with  these  test  files  to  produce 
sample  output  which  will  later  be  used  as  a  compari- 
son with  the  output  generated  from  the  converted 
programs. 

*  A  determination  of  manpower  and  computer  resource 
estimates  -  The  agency  must  develop  a  conversion 
workload  estimate  that  itemizes  manpower,  as  well  as 
the  computer  costs,  to  complete  the  conversion  ef- 
fort. 
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4.    DESCRIPTION/SPECIFICATION  OF  SERVICES 


The  next  four  chapters  address  the  content  of  the  RFP 
for  conversion  products.  Specifically,  these  chapters  point 
out  the  kinds  of  information  that  should  be  included  in  dif- 
ferent sections  of  the  RFP.  This  chapter  deals  with  defin- 
ing the  scope  of  work.    Chapter  5  talks    about  deliverables 

and  acceptance  criteria.  Chapter  6  addresses  how  to  specify 
the  instructions  to  the  offeror  and  chapter  7  discusses 
evaluation    criteria.     It   must    be    emphasized    that  these 

chapters  do  not  comprise  a  boilerplate  for  the  information 
to  be  contained  in  an  RFP  for  conversion  services.  Instead, 
they  contain  general  guidance  concerning  the  types  of  con- 
siderations a  conversion  manager  is  generally  faced  with. 
Each  agency  which  is  engaged  in  developing  an  RFP  for 
conversion    services    should  work  with  their  own  procurement 

department,  as  well  as  GSA's  Federal  Conversion  Support 
Center,  to  derive  the  details  of  the  RFP. 

The  purpose  of  this  chapter  is  to  detail  the  scope  of 
work  which  will  be  performed.  The  SPECIFICATION  OF  SERVICES 
section  is  the  core  of  the  RFP,    since    this    is    where  the 

agency  specifies  exactly  what  is  to  be  converted  and  the 
conditions  and  constraints  that  m.ust  be  adhered  to  by  the 
contractor.      Each    section    in    this    chapter    addresses  a 

separate  area  that  an  agency  should  include  in  an  RFP  to  de- 
fine the  scope  of  work.  Prior  to  the  gathering  of  informa- 
tion necessary  for  this  section,  a  glossary  of  terms  that 
are  used  in  the  RFP  should  be  developed.  The  glossary 
should  then  be  included  as  a  separate  attachment  to  the  RFP. 

Reason  for  Conversion 


The  agency  should  first  provide  background  information 
concerning  the  goals  of  the  agency,  the  way  in  which  the 
source  system  contributes  to  these  goals,  and  a  functional 
description  of  the  source  system.  This  should  be  followed 
by  a  detailed  explanation  of  the  circumstances  necessitating 
the  proposed  conversion.  An  understanding  of  the  reasons 
for  the  conversion  effort,  and  an  awareness  of  the  goals  of 
the  conversion  can  help  the  contractor  decide  upon  a  general 
implementation  strategy,  including  the  choice  of  an  ap- 
propriate conversion  technique  to  use.  This  information  can 
be  included  as  an  attachment  to  the  RFP,  rather  than  embed- 
ded in  the  section  which  describes  the  scope  of  work. 
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Current  Computer  System 


This  section  should  describe  both  the  current  hardware 
and  current  non-application  oriented  software.  The  hardware 
description  should  include  the  manufacturer  and  model  number 
of  the  mainframe,  primary  memory  capacity,  secondary  storage 
capacity,  and  a  complete  description  of  all  peripheral  dev- 
ices. 

The  software  description  should  include  the  name  and 
version  number  of  the  operating  system,  the  compilers,  in- 
terpreters, and  assemblers  available  and  a  description  of 
general  purpose  system  utilities  presently  used  by  the 
source  system.  In  addition,  general  purpose  programs,  writ- 
ten and  used  by  in-house  personnel,  should  be  briefly 
described.  This  information  can  be  included  as  an  attach- 
ment to  the  RFP,  rather  than  embedded  in  the  section  which 
describes  the  scope  of  work. 

Target  Computer  Svstem 

Both  tlie  target  hardware  and  non-application  target 
software  should  be  described  in  this  section.  As  with  the 
current  hardware,  the  description  of  the  target  hardware 
should  also  include  the  manufacturer  and  model  number  of  the 
mainframe,  primary  memory  capacity,  secondary  storage  capa- 
city, and  a  complete  description  of  all  peripheral  devices. 

Similarly,  the  target  software  description  should  in- 
clude the  name  and  version  number  of  the  operating  system, 
the  compilers,  interpreters,  and  assemblers  which  will  be 
available  on  the  target  machine,  and  a  description  of  gen- 
eral purpose  system  utilities  which  will  be  available  on  the 
target  system. 

Charts,  similar  to  the  ones  listed  in  Figure  13  [15], 
can  be  extremely  useful  in  identifying  tasks  which  need  to 
be  accomplished  because  of  differences  both  in  the  hardware 
and  non-application  software  between  the  current  and  target 
systCTis.  These  types  of  charts  can  be  produced  by  the  agen- 
cy and  included  in  this  section  of  the  RFP,  or  prepared  as 
an  attachment  to  the  RFP.  The  charts  can  subsequently  be 
expanded  by  the  contractor  after  the  award. 

Description  of  Applications 

The  most  important  item  to  be  addressed  when  defining 
the  scope  of  work  for  a  conversion  effort  is  to  precisely 
define  the  application  programs  which  are  to  be  converted. 
As  was  mentioned  in  chapter  3,  a  complete  inventory  of  all 
programs,  files,  data  bases,  and  documentation  which  pertain 
to  the  source  syst«n  should  have  been  taken,  prior  to  writ- 
ing the  RFP.  The  information  derived  from  this  inventory  is 
used  to  help  define  the  scope  of  work. 
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The  best  way  to  define  the  applications  to  be  converted 
in  the  RFP  is  to  include  the  conversion  inventory 
worksheets,  described  in  chapter  3,  as  an  attachment  to  the 
RFP.  As  a  minimum,  the  following  information  should  be  pro- 
vided by  the  worksheets: 

*  A  description  of  all  programs  to  be  converted. 
(Figures  1,3,7,8  and  10) 

*  A  description  of  all  files  to  be  converted.  (Fig- 
ures 2,4,9  and  10) 

*  A  description  of  all  data  bases  to  be  converted,  in- 
cluding a  description  of  source  and  target  DBMS  to 
be  used.    (Figure  5) 

Conditions/Constraints 

In  addition  to  a  description  of  what  is  to  be  convert- 
ed, the  Scope  of  Work  needs  to  define  how  it  is  to  be  con- 
verted. In  this  section,  any  and  all  conditions  or  con- 
straints relating  to  the  methods  used  by  the  contractor  in 
implementing  the  conversion  should  be  discussed. 

The  first  condition  or  constraint  which  should  be 
enumerated  is  the  required  use  of  agency  standards  in  per- 
forming the  conversion.  This  may  include  programming  stan- 
dards, documentation  standards,  or  any  other  standard  af- 
fecting any  aspect  of  the  conversion  that  the  agency  wishes 
to  impose  on  the  contractor.  The  standards  which  are  im- 
posed may  be  either  standards  internal  to  the  agency  or  na- 
tional standards,  such  as  American  National  Standards  Insti- 
tute (ANSI)    or    Federal    Information    Processing  Standards 

(FIPS),  to  which  the  agency  may  require  the  contractor  to 
adhere. 

Examples  of  internal  agency  standards  are  conventions 
for  variable  names  or  sub-program  names,  standards  for  pro- 
gramming style  (indentation  of  certain  statements,  organiza- 
tion of  types  of  statements  with  respect  to  other  types  of 
statements)  or  requirements  for  programming  methodology  (the 
target  language  code  must  follow  structured  programming 
methodology  and  must  not  use  any  backward  goto's,  etc.). 

An  example  of  national  standards  which  an  agency  may 
choose  to  invoke  is  the  requirement  for  the  target  program 
to  conform  to  the  ANSI  or  FIPS  standard  for  a  particular 
language.  This  requirement  prohibits  the  contractor  from 
using  extensions  to  the  language,  provided  by  the  compiler 
of  the  target  machine,  in  performing  the  conversion.  Ac- 
cording to  FIPS  PUB  68  (Minimal  BASIC)  and  FIPS  PUB  69  (FOR- 
TRAN),   source    programs,  whether  developed  internally  or  on 
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contract  should  be  limited  to  the  elements  of  the  Federal 
Standard.  Nonstandard  language  features  should  be  used  only 
when  the  needed  operation  or  function  cannot  reasonably  be 
implemented  with  the  standard  features  alone. 

Another  type  of  constraint  which  may  be  imposed  is  the 
requirement  for  the  contractor  to  use  a  specific  conversion 
methodology  (e.g.,  receding,  reprogramming,  redesign.)  Cri- 
teria which  can  be  used  in  helping  to  determine  which 
conversion  technique  to  use  are  described  in  chapter  2. 
However,  unless  the  agency  has  a  specific  reason  for  requir- 
ing a  certain  technique,  the  choice  of  an  appropriate 
conversion  technique  can  be  left  up  to  the  contractor.  Ap- 
propriate performance  requirements  included  in  the  RFP 
(which  will  be  discussed  later  in  this  chapter)  may  force 
the  contractor  into  using  a  specific  conversion  technique  in 
order  to  meet  a  specific  performance  requiranent. 

Performance  Criteria 

In  a  report  by  the  National  Bureau  of  Standards  [3], 
the  authors  concluded  that  the  lack  of  performance  criteria 
in  an  RFP  can  often  times  result  in  a  converted  system  that 
does  not  meet  the  users'  needs.    In  the  past,  the  failure  of 

Federal  agencies  to  include  performance  requirements  as  part 
of  the  conversion  RFP  and  the  resultant  contract,  have 
forced  agency  personnel  to    fine-tune    the    converted  code, 

after  they  have  received  it  as  a  deliverable  under  the 
conversion  contract.  This  is  not  only  extremely  costly  to 
the  agency,  in  labor  hours,  but  even  more  importantly  it  of- 
ten means  that  the  converted  programs  can't  be  used  until 
the  fine-tuning  is  completed.  Since  this  fine-tuning  may 
take  a  year  or  more  until  it  successfully  results  in  the 
converted  programs  executing  according  to  minimum  operation- 
al efficiency  constraints,  the  inclusion  of  comprehensive 
performance  constraints  into  the  RFP  can  save  much  time  and 
effort  later  on. 

Some  types  of  performance  requirements  which  may  be  in- 
cluded in  an  RFP  are  processing  time  criteria,  memory  and 
execution  time  considerations,  and  accuracy  criteria.  Per- 
formance requirements  must  be  measurable  and  verifiable. 
Asking  a  contractor  to  ensure  that  processing  time  be  as 
fast  as  possible,  for  instance,  is  a  meaningless  require- 
ment. 

Accuracy  criteria,  in  the  form  of  required  precision  in 
results  of  arithmetic  operations,  will  more  likely  be  a  ma- 
jor consideration  in  the  scientific,  rather  than  business, 
community.  If  precision  requirements  do  exist,  they  should 
be  specified  on  an  individual  basis,  so  that  the  contractor 
is  not  forced  to  use  excessive  storage  locations  for  greater 
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precision  in  all  programs,  leading  to  disastrous  execution 
time  and  memory  requirements. 

Ideally,  functional  specifications,  which  describe  user 
requirements,  should  exist  for  all  source  programs  and  sys- 
tems.   These  requirements  should  have  formed  the    basis  for 

the  design  of  the  original  programs.  Criteria  for  process- 
ing time  for  the  target  system  can,  and  should,  be  derived 
from  the  existing  functional  specifications  since  the  actual 

functions  of  a  system  should  not  change  during  a  conversion 
effort.  Processing  time  criteria  are  extremely  crucial  if 
the  system  being  converted  is  an  interactive,  rather  than 
batch,  system.  An  increase  of  seconds  in  response  time  of 
the  converted  system  compared  to  the  source  system  can  be 
extremely  crucial  and  may  well  lead  to  users  being  much  more 
reluctant  to  use  the  converted  system. 

Contractor  Responsibilities 

CONVERSION  OF  FEDERAL  ADP  SYSTEMS:  A  TUTORIAL  Q]  lists 
six  major  phases  of  conversion:  the  planning  phase,  the  data 
preparation  phase,  the  translation  phase,  the  unit  testing 
phase,  the  system  testing  phase,  and  the  parallel  testing 
phase.  The  contractor  performing  the  conversion  has  dis- 
tinct and  specific  responsibilities  relating  to  each  of 
these  phases.  These  responsibilities  for  each  of  the  phases 
should    be    detailed    in    the    RFP,  and  are  explained  in  the 

remainder  of  this  chapter. 

The  planning  phase  consists  of  identifying  and  docu- 
menting computer  systems,  programs,  and  data  files  that 
operate  on  the  source  computer  system,  as  well  as  deciding 
how    the    transition    to    the    new  computer  system  should  be 

made.  The  RFP  should  require  the  contractor  to  review  the 
agency's  work  done  during  the  planning  phase  and  provide  a 
schedule  for  the  collection  of  programs,  files,  data  bases, 
and  documentation,  as  well  as  milestones  for  data  prepara- 
tion, conversion,  and  unit,  system,  and  parallel  testing. 
In  addition,  the  contractor  should  be  asked  to  describe,  in 
detail,  all  tasks  that  he  or  she  will  perform  throughout  the 
duration  of  the  contract. 

The  data  preparation  phase  is  the  process  of  gathering 
all  the  materials  that  will  be  used  in  the  conversion.  The 
information  gathered  in  the  planning  phase  is  used  to  assure 
that  all  the  inputs  to  the  conversion  process  (program 
source  listings,  input  files,  record  layouts,  and  documenta- 
tion) are  ready  for  the  conversion.  Test  data  must  also  be 
generated  in  this  phase  to  assure  that  adequate  testing  and 
validation  will  be  performed  on  the  converted  system.  Gen- 
eration of  test  data  can  be  done  either  by  the  agency  or  re- 
quired   of    the    contractor  in  the  RFP.    If  the  agency  staff 
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decides  to  generate  the  test  data,  they  should  make  sure 
that  they  have  a  way  of  ensuring  that  the  test  data  they 
have  generated  executes  a  predetermined  percent  of  the  code. 
On  the  other  hand,  if  the  test  data  is  generated  by  the  con- 
tractor, the  RFP  can,  and  should,  require  the  contractor  to 
ensure  that  the  test  data  executes  a  predetermined  percent 
of  the  code.  Thus,  for  the  data  preparation  phase,  the  RFP 
should  require  the  contractor  to  collect  all  of  the  inputs 
to  the  conversion  process  and  to  generate  test  data  either 
by  utilizing  existing  production  files  or  based  on  criteria 
provided  by  the  agency. 

In  the  translation  phase,  each  source  program  is 
translated  to  run  on  the  target  machine.  The  RFP  should 
state  that  the  contractor  must  convert  each  source  program, 

by  name,  to  the  target  machine  and  target  language.  The 
contractor  should  be  made  responsible  for  providing  all  com- 
puter resources,  facilities,  and  conversion  tools  to  be  used 

during  this  phase. 

The  objective  of  the  unit  testing  phase  is  to  compile, 
execute,  and  test  each  target  program  with  its  test  data, 
and  to  match  the  resultant  execution  output  files  with  those 
produced  on  the  source  computer.  The  RFP  should  require  the 
contractor  to  test  each  program  at  the  unit  level  with  a 
minimum  percent  code  execution  necessary  for  successful 
testing.  If  a  predetermined  percent  of  the  code  is  not  exe- 
cuted, the  contractor  should  be  required  to  revise  the  test 
files  to  achieve  the  desired  code  execution. 

The  system  testing  phase  continues  the  testing  beyond 
the  unit  test.  The  interactions  of  the  various  programs 
which  form  the  system  are  now  tested.  In  this  phase,  the 
job  control  language  commands  necessary  to  execute  each  sys- 
tem are  produced.  The  programs  are  compiled  and  executed  as 
a  system.  The  RFP  should  require  the  contractor  to  test  the 
converted  system  as  a  whole,  using  test  data,  and  to  develop 
all  job  control  statements  necessary  to  execute  the  system. 

Parallel  testing  begins  after  system  testing  is  com- 
pleted. The  production  job  control  language  commands  are 
prepared  and  the  production  files  are  converted.  The  system 
is  updated  to  incorporate  production  maintenance  changes 
made  during  the  conversion.  The  programs  are  compiled  and 
executed,  and  the  outputs  are  compared  to  the  existing  pro- 
duction system.  The  RFP  should  require  the  contractor  to 
provide  a  plan  for  parallel  testing  and  implementation, 
software  aids,  and  training  of  agency  personnel.  Optional- 
ly, the  RFP  may  want  to  call  for  contractor  personnel  on- 
site  for  a  fixed  period  of  time  to  help  parallel  test  and 
implement  the  system. 
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Warranty 

Some  conversion  firms  offer  warranties  which  guarantee 
that  the  converted  programs  will  produce  output  functionally 
equivalent  to  that  produced  by  the  source  programs.  With 
this    warranty,    the    conversion    firm  will  usually  agree  to 

correct  errors  made  by  the  contractor  in  converting  the  pro- 
grams for  a  period  of  either  one  or  two  years  following 
delivery  of  the  programs  to  the  agency.    The    correction  of 

errors  is  done  at  no  additional  charge  to  the  agency.  If  an 
agency  desires  this  type  of  warranty,  it  must  be  specified 
in  the  RFP. 


5.    DELIVERABLES  AND  ACCEPTANCE 


The  deliverables  in  a  conversion  contract  should  be 
derived  from  each  of  the  different  phases  of  conversion. 
Each  deliverable,  including  its  precise  form,  should  be 
clearly  specified  in  the  RFP.  These  deliverables,  besides 
including  actual  source  code,  will  also  include  different 
types  of  documentation.  This  documentation  will  usually  be 
of  two  different  types:  1)  documentation  to  verify  that  a 
certain  phase  of  the  contract  has  been  completed  (e.g.  a  do- 
cument verifying  that  a  specific  program  was  successfully 
tested,    detailing    the    test  data  that  was  used,  and  citing 

the  percent  of  the  code  that  was  executed)  and  2)  documenta- 
tion in  sufficient  detail  to  allow  the  agency  to  understand 
how  the  converted  programs  differ  from  the  source  programs 
and  to  allow  for  future  maintenance  of  the  programs. 

The  suggested  deliverables,  associated  with  each 
specific  phase  of  conversion,  are  listed  below. 

Planning  Phase 

*  Schedule  for  the  collection  of  programs,  files,  data 
bases,  and  documentation,  and  milestones  for  data 
preparation,  conversion,  and  unit,  system,  and 
parallel  testing. 

*  A  detailed  list  and  explanation  of  specific  tasks, 
identifying  program  batches,  and  start  and  ccxnple- 
tion  dates. 

Data  Preparation  Phase 

*  An  accounting  of  all  collected  materials  for  each 
run. 

*  A  description  of  the  test  data  generated  for  each 
program. 

Translation  Phase 

*  Listings  of  each  of  the  translated  programs. 
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*  Any  tools  or  aids  developed  for  the  conversion  -  in- 
cluding all  necessary  tapes,  documentation,  etc. 

Unit  Testing  Phase 

*  A  description  of  the  completed  testing  of  each  con- 
verted program,  detailing  the  test  file  used  and  the 
percent  of  code  executed  by  the  test  data. 

*  A  comparison  of  the  output  of  the  source  and  target 
programs,  showing  identical  ouput  when  utilizing  the 
same  input  data. 

*  A  discussion  of  any  specific  performance  require- 
ments for  a  particular  program  and  an  explanation  as 
to  how  the  unit  testing  phase  verifies  that  the  per- 
formance requirements  are  adhered  to. 

*  Any  test  files  developed  or  modified  by  the  contrac- 
tor. 

System  Testing  Phase 

*  Converted  source  programs  on  magnetic  tape  and  con- 
verted source  program  listings. 

*  Converted  job  control  language  commands  for  each 
system. 

*  A  description  of  the  completed  testing  of  each  con- 
verted system,  detailing  the  test  file  used  and  the 
percent  of  code  executed  by  the  test  data. 

*  A  comparison  of  the  output  of  the  source  and  target 
systems,  showing  identical  output,  when  utilizing 
the  same  input  data  in  the  system  testing  phase. 
The  contractor  must  identify,  and  explain,  any 
places  in  the  output  where  an  identical  match  does 
not  occur. 

*  A  discussion  of  any  specific  performance  require- 
ments for  the  system,  as  a  whole,  and  a  justifica- 
tion as  to  how  these  requirements  are  verified  in 
the  system  testing  phase. 

*  Any  test  files  developed  or  modified  by  the  contrac- 
tor. 
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Parallel  Testing  Phase 


*  A  detailed  plan  for  parallel  testing  and  implementa- 
tion, as  well  as  necessary  software  aids,  and  a  plan 
for  training  of  agency  personnel. 

*  A  program  which  converts  all  source  system  input 
files  to  a  format  acceptable  to  the  target  machine, 

*  A  file  compare  routine,  developed  for  the  target 
machine,  which  will  determine  the  equality  of  two 
files,  and,  thus,  help  the  agency  during  the  paral- 
lel testing  phase. 

Documentation  for  Understandabilitv 

Documentation  which  helps  the  programmer  understand  the 
logic  within  a  program  can  be  presented  in  two  different 
ways:  1)  either  internal  to  the  program  or  2)  external  to 
the  program.  Internal  documentation  takes  the  form  of  non- 
executable statements  in  the  language,  which  serve  as  com- 
ments. The  comment  line  in  FORTRAM  or  the  REM  statement  in 
BASIC  are  examples  of  these    types    of    statements.  Making 

sure  contractors  supply  comments  in  any  programs  they  are 
writing  for  an  agency  is  a  must.  For  a  conversion  contract, 
the  contractor  should  be  made  to  supply  comments  about 
specific  sections  of  the  code  which  proved  exceptionally 
difficult  to  convert  and  any  impact  that  these  sections  of 
the  code  may  have  on  future  maintenance  and  general  under- 
standability  or  readabiltiy.  These  comments  can  be  cited  as 
deliverables  as  a  product  of  the  unit  testing  phase. 

Program  documentation  external  to  the  code  should  also 
be  supplied  by  the  contractor.  If  acceptance  criteria  are 
properly  included  in  the  RFP,  the  contractor  may  have  to  do 
extensive  reprogramming,  or  even  redesign  to  meet  the  per- 
formance requirements.  Updated  documentation  (if  program 
documentation  currently  exists)  or  new  program  documentation 
must  reflect  the  changes  made  to  the  programs  for  the  pur- 
pose cited  above. 

In  addition,  other  types  of  documentation,  designed  to 
help  a  designer,  programmer  or  user  understand  the  converted 
system  may  be  asked  for,  depending  upon  the  conversion 
method  used  (receding,  reprogramming  or  redesign)  or  the  fu- 
ture plans  of  the  agency.  The  following  is  a  partial  list 
of  some  other  documentation  which  may  be  desired  by  the 
agency: 
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*  Operating  instructions,  including  a  description  of 
the  job  control  commands  used. 

*  Training  documents. 

*  Data  file  descriptions. 

*  Program  flowcharts  or  top  down  design  analysis  (only 
if  reprogramming  and  redesign  are  required). 

*  System  flow  charts  (if  redesign  is  required). 

*  Implementation  plan  to  be  used  for  the  remainder  of 
the  conversion  task. 

Acceptance  Criteria 

GAO,  in  a  document  entitled  CONTRACTING  FOR  COMPUTER 
SOFTWARE  DEVELOPMENT— SERIOUS  PROBLEMS  REQUIRE  MANAGEMENT 
ATTENTION  10  AVOID  WASTING  ADDITIONAL  MILLIONS,  [28],  states 
that  "Extensive  acceptance  testing  criteria  and  test  data 
should  be  developed  before  the  contract  is  released  and  ac- 
ceptance tests  contractually  required.  Test  and  acceptance 
criteria — how  software  must  perform  before  it  will  be 
accepted — must  be  identified." 

Acceptance  criteria  comprise  one  of  the  most  important 
parts  of  the  conversion  contract.  Without  adequate  accep- 
tance criteria,  an  agency  may  spend  millions  of  dollars  on 
conversion  and  wind  up  with  a  converted  system  which  is  not 
usable.  Acceptance  of  the  contractor's  deliverables  and  fi- 
nal payment  should  occur  only  when  the  following  conditions 
have  been  met  by  the  contractor,  and  verified  by  the  agency: 

*  All  files  converted. 

*  Program  outputs  equal  -  The  output  of  the  converted 
programs,  utilizing  the  converted  files  must  equal 
the  output  of  the  source  programs,  utilizing  the 
source  files.  The  agency  should  make  sure  it  scru- 
tinizes the  output  of  each  converted  program  for 
equality,  and  checks  to  make  sure  that  a  predeter- 
mined percent  of  the  program  code  was  exercised  by 
each  program  during  the  unit  testing  phase. 

*  System  outputs  equal  -  The  output  of  the  converted 
systons,  utilizing  the  converted  files  must  equal 
the  output  of  the  source  system,  utilizing  the 
source  files. 
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*  Documentation  updated  to  reflect  changes  -  If  possi- 
ble, documentation  should  be  required  in  hard-copy 
as  well  as  some  machine  readable  medium  (computer 
readable  or  word  processing  equipment)  so  that  it 
can  be  revised  more  easily.  This  documentation 
should  include  internal  (comments  in  source  code)  as 
well  as  external  documentation,  as  explained  earlier 
in  this  chapter. 

*  Meets  design  and  functional  specification  criteria  - 

Although  this  is  a  conversion  effort,  rather  than  an 
original  design,  the  agency  must  ensure  that  any  and 
all  design  and/or  specification  criteria  that  are 
included  are  adhered  to  by  the  contractor. 

*  Meets  processing  time  criteria  -  The  agency  must 
designate  acceptable  parameters  for  processing  time, 
making  it  incumbent  upon  the    contractor    to  choose 

the  appropriate  method  of  conversion  (receding, 
reprogramming,  redesign,  etc.)  to  produce  function- 
ally   equivalent    source    code  which  executes  within 

the  constraints  set  up  by  processing  time  parame- 
ters. For  on-line  systems,  maximum  acceptable 
response  time  must  be  specified  by    the    agency  for 

each  set  of  user  interface  functions. 

*  Meets  accuracy  criteria  -  This  entails  specifying  an 
acceptable  level  of  precision  for  arithmetic  opera- 
tions. 

*  Meets  other  performance  constraints  -  This  includes 
run-time  efficiency,  efficient  utilization  of  main 
and  secondary  storage  (including  proper  structuring 
of  data  bases,  when  working  in  a  data  base  environ- 
ment), and  error  checking. 

Audits  should  occur  at  regular  intervals  to  ensure  that 
these  conditions  are  being  met  by  the  contractor. 
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6.    INSTRUCTIONS  TO  OFFEROR 


When  preparing  an  RFP  for  conversion  services,  the 
agency  must  decide  what  information  is  needed  from  the  con- 
tractors in  order  to  effectively  evaluate  their  proposals. 
The  instructions  to  the  offerors  concerning  this  type  of  in- 
formation should  be  included  in  a  separate    section    of  the 

RFP.  To  the  offerors,  these  instructions  specifically 
describe  what  they  are  being  asked  to  do,  with  respect  to 
the  preparation  of  the  proposal. 

The  information  which  the  offeror  is  asked  to  provide 
will  subsequently  form  the  basis  for  evaluating  the  propo- 
sal, based  on  the  evaluation  criteria  provided  in  the  RFP. 
This  section  of  the  RFP  should  contain  a  warning  that  insuf- 
ficient data  or  inappropriate  data  may  be  considered  as  evi- 
dence of  a  lack  of  understanding  of  the  intended  effort,  and 
will  affect  the  evaluation  score. 

The  following  sections  of  the  offeror's  proposal  are 
needed,  as  a  minimum,  in  order  to  perform  a  complete  evalua- 
tion.   The  offeror  should  be  instructed,  in  this  section  of 

the  RFP,  to  provide  the  following  information: 

1)  Work  Statement  -The  offeror  should  be  instructed  to  in- 
clude the  following  three  areas  of  discussion  in  his  Work 
Statement: 

i)  A  discussion  of  the  technical  and  management  problems 

involved  in  the  conversion,  demonstrating  a  clear  under- 
standing of  all  the  issues. 

ii)  An  outline  and  discussion  of  a  proposed  technical  ap- 
proach for  accomplishing  the  conversion.  The  proposed 
technical  approach  should  include  a  proposed  Implementa- 
tion Plan  which  identifies  tasks  to  be  accomplished, 
along  with  projected  completion  dates.  The  offeror 
should  provide  a  detailed  explanation  and  description  of 
the  proposed  methodology  to  be  used,  including  a  descrip- 
tion of  which  conversion  technique(s)  (receding,  repro- 
gramming,  redesign)  will  be  used  for  each  program  or 
group  of  programs,  and  an  explanation  of  why  that  partic- 
ular technique  is  most  effective  for  these  programs.  The 
offeror  should  identify  any  automated  conversion  aids 
that  are  presently  available,  or  that  may  be  developed 
for  this  contract.  The  description  of  the  automated 
tools  should  also  provide  an  indication  of  the  effective- 
ness of  that  particular  tool  (i.e.,  the  percentage  of 
manual  coding    that    remains    after    utilization    of  the 

tool.)  Finally,  the  offeror  should  submit  a  proposed  test 
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plan,  which  describes  the  methodology  for  ensuring  satis- 
factory program  design  and  testing,  including  quality  as- 
surance. 

iii)  A  discussion  of  the  phasing  for  the  contract,  based 
upon  the  technical  approach  being  proposed. 

2)  Offeror  Experience  and  Capability  -  This  section  should 
include  sufficient  information  to  permit  evaluation  of  the 
previous  and  current  experience  and  effectiveness  of  the  of- 
feror in  similar  or  related  work,  and  to  demonstrate  the 
offeror's  current  capability  for  carrying  out    the  intended 

contract  effort. 

At  a  minimum  this  section  should  include: 

i)  Previous  conversions  performed  by  offeror,  describing 
the  source  and  target  systems,  including  a  discussion  of 
the  scope  and  complexity  of  the  conversion  effort. 

ii)  Principal  clients  served  in  performing  these  conver- 
sions, including  pertinent  dates,  contract  numbers,  ap- 
proximate cost,  sponsor  contact  (name,  organization, 
telephone  number,  and  address),  and  offeror's  key  person- 
nel involved. 

iii)  Level  of  involvement  of  planned  subcontractors  under 
the  proposed  contract,  including  sufficient  detail  to 
permit  overall  evaluation. 

iv)  Brief  overall  capability  identification  of  offeror. 

v)  Identification  of  prospective  supporting  units  or  fa- 
cilities which  may  be  utilized  in  accomplishing  the  pro- 
posed effort. 

3.)  Proposed  Contract  Kev  Personnel  -  This  section  should  in- 
clude such  information  necessary  to  permit  evaluation  of  the 
quality,  competence,  and  experience  of  the  personnel  pro- 
posed to  be  available  for  the  performance  of  the  intended 
contract  effort.  The  offeror  should  be  required  to  provide, 
for  each  prospective  key  person,  a  resume  which  includes,  at 
a  minimum: 

i)  Name, 

ii)  Title, 

iii)  Brief  description  of  previous  work  experience 
(dates,  duties,  and  onployers),  indicating  whether  the 
experience  was  managerial  or  technical. 
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iv)  Detailed  statement  of  previous  experience  relevant  to 
the  intended  effort  and  of  recent  and  current  work  ex- 
perience. (Names,  current  telephone  numbers  and  ad- 
dresses, where  possible,  of  supervisors  or  others  with 
direct  knowledge  of  individual's  effort  and  of  technical 
sponsors  should  be  supplied), 

v)  Specific  capabilities,  such  as  programming  languages 
and  computers  used, 

vi)  Education, 

vii)  Publications,  patents,  and  other  presentations  (a 
copy  to  be  supplied,  upon  request,  of  any  listed  refer- 
ence not  otherwise  readily  available), 

viii)  Labor  category  and  relative  percentile  salary  level 
within  category, 

ix)  Proposed  level  of  effort  availability. 

it)  Certification  -  If  any  proposed    Contract    Key  Personnel 

are  not  presently  employees,  the  offeror  should  be  informed 
that  he  or  she  must  be  involved  in  current  good  faith  nego- 
tiations with  prospective  employees  whose  resumes  have  been 
submitted  and  that  the  offeror  has  ascertained  that  the  ap- 
plicant will  be  available  to  work  under  the  proposed  con- 
tract. The  offeror  should  also  be  asked  to  provide  updated 
information  during  negotiations  and  prior  to  award  when  any 
proposed  Contract  Key  Personnel  are  no  longer  available. 

5.)  Technical  Management  Plan  -  The  offeror  should  describe 
the  organization  and  management  plan  which  will  be  utilized 
for  the  technical  management  of  the  proposed  contract.  This 
description  should  demonstrate  an  understanding  of  the  na- 
ture of  the  proposed  effort  and  its  potential  problems,  and 
how  issues  will  be  handled  in  a  timely  manner  at  the  proper 
level  of  authority.    The  plan  should  include  the  following: 

i)  A  staffing  plan  indicating  how  the  proposed  key  per- 
sonnel will  be  assigned  and  the  disposition  of  their  time 
between  the  proposed  contract  and  other  work  in  progress. 

ii)  A  clear  and  complete  description  of  lines  of  activi- 
ty; interaction  with  the  Contracting  Officer's  Technical 
Representative  (COTR);  and  control  of  scheduling  of 
tasks,  reports  and  other  activities. 

iii)  Identification  and  discussion  of  real  or  apparent 
possible  sources  of  conflict  of  interest,  that  is,  a  si- 
tuation which  may  diminish  the  offeror's  capacity  to  give 
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impartial,  technically  sound,  objective  assistance  and 
advice.  The  term  "offeror"  in  this  subparagraph  includes 
any  staff,  subcontractors,    consultants,    or    any  others 

connected  with  the  offeror  who  may  influence  the  proposed 
contract  results.  The  proposal  should  also  identify  and 
discuss    planned    efforts    of  the  offeror  to  minimize  the 

effect  of  any  conflict  of  interest.  The  offeror  should 
provide  updated  information  during  negotiations  and  prior 
to  award,  if  any  changes  are  appropriate. 

iv)  A  description  of  the  project  management  and  control 
tools  and  techniques  proposed  and  the  effectiveness  of 
such  tools. 


6)  Modifications  -  Any  proposed  modifications  of  the  pro- 
posed contract  as  described  in  the  RFP  should  be  specifical- 
ly itemized  and  discussed  in  this  section.  These  modifica- 
tions may  differ  in  technical  approach,  level  of  effort  pro- 
posed, and/or  period  of  performance  as  long  as  all  the  re- 
quirenents  and  deliverables  of  the  solicitation  are  met. 
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7.    EVALUATION  AND  AWARD  FACTORS 


Once  the  offerors  prepare  their  proposals,  based  on  the 
instructions  given  to  them,  the  information  they  have  pro- 
vided becomes  the  basis  for  evaluating  the  relative  merits 
of  their  proposals.  Thus,  the  evaluation  criteria,  which 
are  discussed  in  this  chapter,  are  derived  from  the  instruc- 
tions given  to  the  offeror.  In  the  remainder  of  this 
chapter,  suggested  evaluation  factors  are  discussed,  and  a 
suggested  weighting  factor  is  assigned  to  each.  The  weight- 
ing factor  indicates  the  relative  importance  associated  with 
each  of  the  factors  during  evaluation. 

Technical  Approach  to  the  Statement  of  Work 

The  information  provided  by  the  offeror  in  the  Work 
Stat^nent  is  the  first  area  to  be  considered  in  evaluating 
the  proposal.  The  technical  approach  to  the  stat^nent  of 
work  is  the  section  of  the  proposal  where  most  of  the  cru- 
cial information  is  obtained  and  consequently  deserves  to 
have  a  high  weighting  factor  assigned  to  it.  It  is  in  this 
section  where  the  agency  should  discover  if  the  offeror  ac- 
tually understands  the  work  involved  and  if  the  offeror  has 
the  capability  to  do  the  job. 

When  scoring  each  section  of  a  proposal,  it  is  usually 
helpful  to  have  a  checklist  of  sub- factors,  pertinent  to  the 
area,  to  help  decide  how  many  points  to  assign  to  each  of- 
feror. For  the  sake  of  completeness,  the  offeror  should  ad- 
dress as  many  of  the  factors  in  the  checklist  as  possible. 
However,  the  offeror  should  not  be  guaranteed  a  good  score 
just  because  all  of  the  factors  cited  below  have  been  ad- 
dressed. Quality  is  still  the  most  important  criteria  in 
scoring  the  proposal.  Therefore,  the  content  of  the 
offeror's  response  concerning  the  areas  in  the  checklist, 
and  whether  or  not  the  offeror  demonstrates  an  understanding 
of  the  intended  effort  and  the  ability  and  willingness  to 
perform  the  conversion  are  more  important  than  the  number  of 
sub- factors  that  are  addressed  in  his  proposal.  The  follow- 
ing checklist  is  proposed  for  helping  to  evaluate  the  techn- 
ical approach  to  the  statement  of  work: 

*    Conceptual  soundness  of  approach. 

-The  overall  approach  should  make  sense  and 
should  be  an  appropriate  approach  for  this  par- 
ticular system  of  programs. 
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Schedule  and  plan  to  implement  the  approach. 

-The  major  phases  of  conversion  should  be  identi- 
fied by  the  offeror. 

-The  correct  activities  should  be  planned  for 
these  phases. 

Identification  of  conversion  planning  elements. 

-The  offeror  should  demonstrate  an  understanding 
of  what  is  involved  in  the  planning  phase  of 
conversion. 

-A  comprehensive  conversion  plan  should  be 
presented  by  the  offeror. 

Degree  of  use  and  quality  of  conversion  aids  pro- 
posed. 

-The  offeror  should  identify  the  conversion  aids 
to  be  used. 

-The  offeror  should  also  identify  the  effective- 
ness of  these  conversion  aids  (i.e.,  the  percen- 
tage of  manual  coding  that  remains  to  be  done 
after  utilizing  the  tool). 

Offeror's  approach  to  translation. 

-The  offeror  should  present  a  detailed  explana- 
tion and  description  of  the  proposed  methodology 
to  be  used,  including  a  description  of  which 
technique(s)  (receding,  reprogramming, . redesign) 
shall  be  used  for  each  program  or  group  of  pro- 
grams, and  an  explanation  as  to  why  that  tech- 
nique is  most  effective  for  these  programs. 

-The  offeror  should  discuss  how  non-standard  code 
will  be  treated  and  whether  or  not  I/O  and  non- 
standard code  will  be  modularized. 

Offeror's  approach  to  quality  control. 

-The  offeror  should  discuss  quality  control  for 
incoming  materials  as  well  as  quality  control 
during  the  translation  phase. 

Offeror's  testing  philosophy. 

-A  comprehensive  test  plan  should  be  presented  by 
the  offeror. 
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*  Acceptance  testing  and  verification. 

-Detailed  acceptance  tests  should  be  proposed  by 
the  offeror. 

-Performance  considerations  should  be  taken  into 
account  by  the  offeror. 

The  offeror's  philosophy  of  implementation  is  among  the 
most  important  information  contained  in  an  offeror's  state- 
ment of  work.  The  following  factors  concerning  implementa- 
tion philosophy  should  be  taken  into  account  in  scoring  the 
offeror's  technical  approach  to  the  statement  of  work: 

*  Maintainability  of  converted  code  -  This  factor  con- 
cerns the  quality  of  the  converted  code. 

-Will  the  code  be  readable  and  maintainable? 

-V/hat  types  of  standards  will  be  used,  besides 
the  ones  provided  by  the  agencies? 

-How  does  the  offeror  view  comments  and  the  need 
for  program  documentation? 

*  Training . 

-The  offeror  should  discuss  plans  for  training  of 
both  his  or  her  staff  and  the  agency  staff. 

-Specifically,  training  for  programmers, 
analysts,  operators,  users,  and  management  needs 
to  be  discussed. 

*  Understanding  of  and  approach  to  problem  areas  -  The 
offeror  should  address  the  following  questions: 

-How  will  distinct  differences  in  canputer  archi- 
tecture affect  the  conversion? 

-Will  problems  arise  because  of  different  word 
sizes  on  the  two  machines? 

-If  so,  how  will  these  be  handled? 

-Will  problems  arise  because  of  different  collat- 
ing sequences? 

-Will  differences  in  JCL  cause  special  problans? 
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-Will  differnces  in  primary,  as  well  as  secondary 
memory  between  the  two  machines  cause  problems? 

-If  so,  how  will  these  problems  be  handled? 

-How  will  machine  dependencies  in  the  source  code 
be  handled? 

-Is  program  documentation  sufficient  to  address 
some  of  the  above  problems? 

Qualification  of  Offeror 

In  this  section  of  the  proposal,  the  offeror  details 
the  experience  of  the  firm  and  corporate  management,  exclud- 
ing a  detailed  profile  of  key  personnel.  This  section,  as 
well  as  the  section  on  key  personnel,  is  extremely  critical 
in  evaluating  the  proposal  because  the  success  of  a  computer 

system  conversion  depends  heavily  on  the  experience  of  the 
entity  performing  the  conversion.  Thus,  a  high  weighting 
factor    is  suggested.    Comprehensive,  detailed  experience  in 

conversion  is  difficult  to  find  since  conversions  occur  in- 
frequently (once  every  five  to  seven  years),  and  the  people 
who  perform  the  conversions    frequently    move    on    to  other 

areas  in  data  processing,  such  as  design  or  original  pro- 
gramming. Firms  which  specialize  in  conversions  and  who 
maintain  people  who  build  up  an  expertise  in  this  discipline 
are  in  great  demand.  Previous  conversions,  performed  by  the 
offeror,  should  be  as  similar  to  the  conversion  addressed  in 
this  RFP  as  possible. 

The  following  checklist  is  proposed  as  an  aid  in  help- 
ing to  score  the  qualifications  of  the  offeror  and/or  sub- 
contractor: 

*  The  degree  of  general  experience  in  software  conver- 
sion -  The  offeror  should  provide  details  of  similar 
previous  conversions  performed,  describing  the  scope 
and  complexity  of  the  effort,  the  source  and  target 
systems,  and  the  principal  clients  served  in  per- 
forming these  conversions.  References  should  be 
checked. 

*  Specific  experience  in  target  language  or  machine  - 
The  offeror  should  describe  experience  in  converting 
systems  to  the  target  language  specified  in  this 
solicitation    as    well    as    to    the    target  computer 

specified  in  this  solicitation. 
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*  The  available  facilities  -  The  offeror  should 
describe  the  facilities  which  will  be  used  to  per- 
form this  conversion  and  specify  how  these  facili- 
ties were  utilized  in  performing  other  conversions. 

*  Level  of  management  participation  in  the  conversion 
process  -  Since  the  major  difficulties  associated 
with  conversions  are  very  often  management  rather 
than  technical  problems,  the  offeror  should  demon- 
strate the  conversion  management  expertise  which  is 
retained  by  the  firm. 

*  Variety  of  conversion  experience  -  Although  not  as 
important  as  the  other  factors,  a  variety  of  experi- 
ence will  allow  the  contractor  to  make  difficult  de- 
cisions concerning  unexpected  problems,  based,  in 
many  instances  on  similar  instances  in  prior  conver- 
sions. 

*  Corporate  resources  -  Although  larger  doesn't  always 
imply  better,  the  offeror  must  demonstrate  that  suf- 
ficient technical  and  managerial  staff  are  available 
to  do  the  job. 

Qualification  of  Proposed  Key  Personnel 

In  this  section  of  the  proposal,  the  offeror  details 
the  experience  of  the  key  personnel.  Ccmpetent,  experienced 
conversion  specialists  are  extremely  difficult  to  find. 
Thus,    this  section  of  the  proposal  must  be  scrutinized  very 

carefully  to  determine  whether  or  not  the  key  personnel  are 
actually  qualified.  A  high  weighting  factor  is  suggested 
for  Qualification  of  Proposed  Key  Personnel. 

The  following  checklist  is  proposed  as  an  aid  in  help- 
ing to  score  the  qualifications  of  the  key  personnel: 

*  Relative  experience  of  project  team  -  The  offeror 
must  demonstrate  that  the  project  team  has  com- 
petence and  experience  to  perform  the  conversion. 
Specific  capabilities,  such  as  programming  languages 
utilized,  conversion  tools  utilized,  and  computers 
worked  on  should  be  detailed  in  this  section.  A 
complete  employment  history,  including  relevant 
current  and  recent  work  experience,  project  names, 
descriptions  and  degree  of  involvement,  and  clients 
should  be  provided  here.  References  should  be 
checked . 
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*  Mix  of  skills  of  proposed  personnel  -  The  offeror 
must  demonstrate  that  the  project  team  has  a  suffi- 
cient mix  of  skills  to  cover  the  broad  areas  in- 
volved in  the  different  phases  of  conversion. 

*  Relative  experience  of  project  manager  -  The  project 
manager  is  the  most  important  of  the  key  personnel 
proposed.  He  or  she  must  possess  a  broad  background 
of  managerial  experience  in  past  conversion  projects 
as  well  as  enough  low-level  conversion  expertise  to 
make  decisions  affecting  the  technical  direction  of 
the  project. 

Reasonableness  of  Management  Plan 

In  this  section,  the  offeror  describes  the  organization 
and  management  skills  which  will  be  utilized  for  the  techni- 
cal management  of  the  proposed  contract.    Managonent  skills 

involve  staffing,  scheduling,  reporting,  managing  personnel, 
and  controlling  materials.  This  description  should  demon- 
strate how  issues  will  be  handled  in  a  timely  manner,  at  the 
proper  level  of  authority.  A  relatively  low  weight  is 
recommended  for  this  factor.  The  following  checklist  is 
proposed  as  an  aid  in  helping  to  score  the  reasonableness  of 

the  management  plan: 

*  A  staffing  plan  indicating  how  the  proposed  key  per- 
sonnel will  be  assigned,  and  the  disposition  of 
their  time  between  the  proposed  contract  and  other 
work  in  progress  must  be  provided  by  the  offeror. 

*  A  detailed  schedule,  which  is  consistent  with  both, 
the  goals  of  the  conversion,  as  well  as  the  limita- 
tions of  the  conversion  effort  should  be  provided  by 
the  offeror. 

*  Responsible  management  officials  must  be  named, 

*  Lines  of  activity  and  responsibility  must  be  clearly 
and  completely  described. 

*  Interaction  with  the  Contracting  Officer's  Technical 
Representative  must  be  detailed. 

*  Reporting  dates  and  methods  should  be  given. 

*  Milestones  should  be  clearly  identified. 
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*  The  offeror  should  demonstrate  his  or  her  ability  to 
respond  on  short  notice. 

*  The  offeror  should  demonstrate  his  or  her  flexibili- 
ty to  respond  to  changed  conditions. 

*  Conflicts  of  interest  should  be  discussed  by  the  of- 
feror . 

*  A  description  of  the  project  management  and  control 
tools  and  techniques  should  be  provided  by  the  of- 
feror . 

Cost 

If  the  contract  is  fixed  price,  the  agency  has  deter- 
mined   that  the  RFP  precisely  defines  the  scope  of  work.  In 

this  case,  the  responsibility  is  on  the  contactor  to  deliver 

a  converted  system  according  to  specifications.  Since  the 
agency  is  contractually  assured  of  a  correct  converted  sys- 
tem,    regardless    of   which    offeror    is  selected,  the  least 

costly  offeror  becomes  very  attractive.  Conversely,  the 
determination  that  a  cost  plus  contact  is  needed,  implies 
that  the  scope  of  work  is  not  as  precise,  and    the  agency  is 

depending  upon  the  contractor's  best  efforts  to  perform  the 
conversion.  In  this  case,  the  quality  of  the  contractor  is 
more  important  than  the  cost.  Thus,  a  relatively  low 
weighting  factor  is  suggested  for  cost  with  the  assumption 
that  the  contract  will  be  some  sort  of  cost  plus  contract 
(cost  plus  fixed  fee,  cost  plus  incentive  fee,  etc.).    If  it 

is  decided  that  the  contract  shall  be  a  fixed-price  con- 
tract, then  the  weight  associated  with  the  cost  factor  will 
have  to  increase  significantly,  and  the  weight  for  the  other 

evaluation  factors  identified  must  decrease  proportionately. 

However,  as  stated  earlier,  many  conversions  do  not 
lend  themselves  to  fixed  price  contracts  since  the  scope  of 
the  effort  is  not  known  with  great  certainty,  especially  if 
performance    and  efficiency  constraints  are  included  as  part 

of  the  acceptance  criteria.  In  this  case,  cost  should  be  a 
relatively  smaller  factor  than  the  other  factors  identified, 
since  the  selection  of  a  low  cost,  but  only  marginally  qual- 
ified technical  proposal  may  very  well  result  in  a  converted 
system  which  does  not  meet  the  agency  needs,  and  is  thus, 
unusable  as  it  stands.  Much  expenditure  of  agency 
resources,  in  both  manpower  and  cost,  would  then  be  neces- 
sary in  order  to  tune  the  converted  system  to  the  point 
where  it  would  be  usable.  In  the  long  run,  this  approach 
would  not  only  be  highly  detrimental  to  the  agency's  goals 
and  needs,  but  would  actually  result  in  a  conversion  which 
is  more  costly,  over  its  systems  life  cycle. 
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8.  CONCLUSIONS 


Probably  the  most  important  thought  to  keep  in  mind 
when  writing  an  RFP  for  conversion  services  is  to  include, 
in  the  RFP,  everything  that  you  want  the  contractor  to  do. 
Don't  assume  that  anything  will  be  done  if  it  is  not  specif- 
ically stated  in  the  RFP.    Avoid  the  pitfall    of   having  to 

rely  on  the  contractor  for  follow-on  work  because  the 
deliverables  have  not  been  sufficiently  thought-out  and 
specified.     Only    close    attention    to  every  detail  of  what 

should  be  in  the  RFP  can  assure  a  successful  conversion  ef- 
fort. This  chapter  presents  a  summary  of  the  most  crucial 
aspects  of  the  RFP. 

Specification  of  Services 

In  this  section  of  the  RFP,  all  software  which  is  to  be 
converted  must  be  precisely  defined.  There  is  no  easy  way 
to  accomplish  this.    A  ccmplete  inventory  of    all  programs, 

files,  data  bases,  and  documentation  must  be  done  and  the 
results  from  this  inventory  included  as  an  attachment  to  the 
RFP.     Any  constraints  which  the  agency  would  like  to  impose 

on  the  contractor  must  be  stated  explicitly. 

If  a  specific  conversion  technique  is  not  required  by 
the  RFP,  the  contractor  will  almost  surely  choose  to  perform 
a  line-for-line  conversion  since  this  is  the  easiest  and 
least  costly  method.  Similarly,  if  the  RFP  does  not  specify 
performance  criteria,  the  contractor  will  probably  choose  to 
perform  a  line-for-line  conversion  since  there  is  no  incen- 
tive to  improve  the  operating  efficiency  of  the  system. 
Even  if  perfcanance  criteria  can  not  be  derived  and,  thus, 
are  not  included  in  the  RFP,  there  may  be  another  reason  for 
asking  for  reprogramming  or  redesign  rather  than  a  line- 
for-line  conversion.  Especially  when  converting  from  assem- 
bly language  to  a  higher  level  language,  such  as  COBOL,  a 
line-for-line  conversion  will  result  in  converted  code  which 
is  much  larger  than  it  should  be. 

Deliverables  and  Acceptance 

The  deliverables  associated  with  each  phase  of  conver- 
sion and  the  acceptance  criteria  must  be  explicitly  stated. 
Minimum  acceptance  criteria  include: 

*    All  files  converted, 
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Program  outputs  equal, 
System  outputs  equal, 

Documentation  updated  to  reflect  changes. 
Meets  design  and  functional  specification  criteria. 
Meets  processing  time  criteria. 
Meets  accuracy  criteria. 
Meets  other  performance  constraints. 

Instructions  to  Offeror 

The  instructions  to  the  offeror  should  request  all  in- 
formation which  is  needed  in  order  to  evaluate  the  offeror's 
proposal.  These  instructions  should  address  the  following 
areas: 

*  Work  statement, 

*  Offeror's  experience  and  capability, 

*  Proposed  contract  key  personnel, 

*  Certification, 

*  Technical  management  plan, 

*  Modifications. 

Evaluation  and  Award  Factors 

The  choice  of  evaluation  factors  and  the  weight  as- 
signed to  them  are  very  important  since  this  choice  will  ul- 
timately decide  which  offeror  receives  the  contract  award. 
The  suggested  evaluation  factors  are: 

*  Technical  approach  to  the  statement  of  work, 

*  Qualification  of  offeror, 

*  Qualification  of  key  personnel. 


ft 
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*  Reasonableness  of  management  plan, 

*  Cost. 

Conversion  contracting  can  be  an  experience  which  is 
weighed  down  with  problems  if  it  is  not  well  thought-out. 
Many  problems  can  be  avoided,  and  a  smooth  transition  to  the 
target  machine  can  be  accomplished,  by  thoroughly  planning 
the  contractors'  activities    and    effectively  ccanmunicating 

these  plans  to  them.  An  agency  cannot  expect  to  receive 
anything  which  is  not  clearly  specified  in  the  contract. 
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Technical  Notes — Studies  or  reports  which  are  complete  in  them- 
selves but  restrictive  in  their  treatment  of  a  subject.  Analogous  lo 
monographs  but  not  so  comprehensive  in  scope  or  definitive  in 
treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final 
reports  of  work  performed  at  N  BS  under  the  sponsorship  of  other 
government  agencies. 

Voluntary  Product  Standards — Developed  under  procedures 
published  by  the  Department  of  Commerce  in  Part  10,  Title  15,  of 
the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all 
concerned  interests  with  a  basis  for  common  understanding  of  the 
characteristics  of  the  products.  NBS  administers  this  program  as  a 
supplement  lo  the  activities  of  the  private  sector  standardizing 
organizations. 

Consumer  Information  Series — Practical  information,  based  on 
NBS  research  and  experience,  covering  areas  of  interest  to  the  con- 
sumer. Easily  understandable  language  and  illustrations  provide 
useful  background  knowledge  for  shopping  in  today's  tech- 
nological marketplace. 

Order  the  above  NBS  puhlicaiicms  from:  Superiniendeni  oj  Docu- 
menis.  Government  Printing  Office.  Washington.  DC  20402. 
Order  the  following  NBS  publications — FIPS  and  NBSIR's — from 
the  National  Technical  Information  Services.  Springfield.  VA  22161 . 

Federal  Information  Processing  Standards  Publications  (FIPS 
PUB) — Publications  in  this  series  collectively  constitute  the 
Federal  Information  Processing  Standards  Register.  The  Register 
serves  as  the  official  source  of  information  in  the  Federal  Govern- 
meni  regarding  standards  issued  by  NBS  pursuant  to  the  Federal 
Property  and  Administrative  Services  Act  of  1949  as  amended. 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  b>  Ex- 
ecutive Order  1  1717  (38  FR  12315,  dated  May  II,  1973)  and  Part  6 
of  Title  15  CFR  (Code  of  Federal  Regulations). 

NBS  Interagency  Reports  (NBSIR) — A  special  series  of  interim  or 
final  reports  on  work  performed  by  NBS  for  outside  sponsors 
(both  government  and  non-government).  In  general,  initial  dis- 
tribution is  handled  by  the  sponsor;  public  distribution  is  by  the 
National  Technical  Information  Services,  Springfield,  VA  22I6I, 
in  paper  copy  or  microfiche  form. 
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